MINISTRY FOR DEVELOPMENT OF INFORMATION TECHNOLOGIES AND COMMUNICATIONS OF THE REPUBLIC OF UZBEKISTAN
TASHKENT UNIVERSITY OF INFORMATION TECHNOLOGIES
FACULTY OF «ECONOMICS AND MANAGEMENT IN ICT SPHERE»
«MANAGEMENT AND MARKETING» DEPARTMENT
|
|
«Confirmed» Vise rector of education _______________________
“___”___________2016 year
|
EDUCATIONAL METHODICAL COMPLEX
From the discipline of
«BASICS OF CUSTOMER RELATIONSHIP MANAGEMENT SYSTEM»
Tashkent-2016
The education methodical complex created for the field of study: 5350300 - Economics and management in ICT sphere.
Compiler: Gafurova D.R.
Reviewer:
Ismoilova G.F. – TUIT, Phd., assistant professor
Yuldasheva S.P. – TIAW, Phd., assistant professor
The education methodical complex was discussed and approved at a meeting of «Management and marketing» department (¹_1_ from "30" _08__2016_).
Head of department Sh.A.Tursunov
The education methodical complex was discussed and approved at a meeting of the faculty of Economics and management in ICT sphere (¹_1_ from "31" _08__2016_)
Dean of the Faculty EMICTS Sh.Sh.Turayev
THEME 1.BASICS OF ORGANIZATIONAL SYSTEM OF CRM
Now that we have established what we mean when we say "CRM", and provided a high-level outline of the book, let's explore why a business, or for that matter any organization, might embark on such a program. What is the value of CRM?
Supporting a Data-Driven, Learning Organization
The marriage of a set of well-documented, consistently-executed processes, with a business application that supports, monitors, and reports on them provides the foundation for an agile organization that learns and evolves. This agility can help you stay one step ahead of your competition. In addition to its direct role in helping users execute business processes efficiently, the CRM application's reports and dashboards act as "instrumentation" for your organization- supporting agility by enabling you to constantly assess what is working and what is not, to test hypotheses and experiment with improvements, and then to make data-driven decisions based on the results.
Consider the following exchange with a sales executive:
CRM Consultant: Do you know why your customers buy from you?
Manager. I have some idea. They buy because of customer service, and our product is superior.
CRM Consultant: How do you know this? Manager: From talking with some of our customers.
CRM Consultant: Do you know which of these factors is most important to which customers?
Manager: No, I suppose not.
CRM Consultant: Do you know who you lose deals to most often and why?
Manager: I have an idea, but again I don't have any empirical data to support it.
This is a fairly common interaction with an organization that has either not attempted or not succeeded with implementing a CRM program. We would get similar responses if we asked about sales pipeline visibility, sales cycle duration, lost deal analysis, or customer service inquiry data (how long do inquiries take to get resolved, how many are resolved in the first call, etc.). You have heard the old aphorism " You can't manage what you can't measure" - consistent processes and a sophisticated CRM application can provide the platform needed to measure and manage.
Wringing out Inefficiencies and Increasing Employee Productivity
Understanding your current processes is the first step in beginning to analyze potential improvements that can be enabled by your CRM application. Entire books are dedicated to process definition and improvement so we will not go into great detail on those topics in this book; our goal is to show how a CRM system can help create efficiencies in your processes with proper analysis and implementation. A few examples of efficiency gains from CRM can be:
• Improve lead management by feeding leads directly from website contact forms to the appropriate sales team's work queue in CRM
• Automatically assign inbound leads to the appropriate sales rep, based on geography, category, etc. This auto-assignment gets leads in the hands of sales reps more quickly.
• Automatically escalate or re-assign service issues, based on defined criteria such as priority, issue, age, type, etc. This results in more efficient issue management and improved customer experience. Service issues can no longer "slip through the cracks".
• Alert management on big sales deals - when sales deals are above a certain revenue threshold, the CRM application can automatically alert the sales leadership team so that they have visibility to the deal and can assist the account team.
• Business intelligence elements of CRM can be used to profile leads who have been successfully converted to customers, and then score inbound leads to help sales team members prioritize their calls to focus on the leads most similar to past successful leads.
• Managing quote generation within CRM ensures sales reps create valid quotes (including necessary and compatible components/products), and ensures all reps use correct pricing and up-to-date product availability. This reduces ramp-up time for new sales team members, and slashes frequency of invalid quotes.
• Relate all interactions (phone calls, important e-mail, e-mail newsletters, trade show attendance, etc.) with customers to analyze sales drivers, win or loss reasons, repeat business, etc.
Providing a Better Customer Experience
Providing customers with the most satisfying and effective interactions possible is an increasingly important competitive differentiator. Customers are not nearly as loyal today - they can often simply search the web and find a "better" alternative to your product or service within minutes. In addition, technology tools such as blogs, ratings sites, and social networks have increased the scale and impact of the consumer's "word-of-mouth", making positive customer experiences even more important.
Customers' expectations of what defines an acceptable interaction are continually evolving, and today include the following:
• Each representative they interact with should have access to the entire organization's past interactions with you, from purchasing to service. Customers calling in for service should not need to be transferred around just to find information from their last conversation with your organization.
• Self-service options should be available so that customers can get information or initiate basic transactions themselves, 24 hours a day, 7 days a week.
• Your organization should communicate with them via whatever mode they prefer- email, phone, text message, etc.
An easy study of how customer's expectations around interactions have changed is to consider the retail banking space. It was not too long ago that all retail banking was done inside bank branches with tellers during "banker's hours". Over time, the
industry introduced one innovation after another to provide better and better experiences for customers (often reducing costs at the same time). First drive- through banking was introduced, then ATM machines, and then internet banking. Somewhere along the line banks began opening for longer hours to make them more convenient. And now there are several banks that let you transact via your mobile phone, and will send you balance updates via text messages.
CRM programs support your organization's effort to meet these expectations in a number of ways:
• The evaluation of business processes from the customer perspective associated with a CRM program can result in changes that improve customer satisfaction.
• The CRM application serves as a central hub of customer information, shared by all customer-facing employees, helping them each present an informed face to the customer.
• The CRM application workflow automation can provide a platform to send communications to customers automatically based on events.
• The CRM application can act as the data store for a customer web portal to enable self-service.
• Data mining of the CRM application can identify products, services, and promotions that may be of interest to customers based on their profile.
Your CRM program provides a platform for gathering customer information, and making it easily available to business leaders for review and analysis. Decisions that were once made on anecdotal evidence, or only after lengthy and arduous data collection and aggregation, can be easily supported by relevant information from the CRM application. New insights into the organization and its customers can be gained, identifying new opportunities or competitive threats.
Some common areas where CRM data can help inform decision making include the following, with questions that might be answered in each area:
Sales forecasting
Will we likely make our revenue targets this month/quarter? How will sales be distributed across regions and product lines?
Sales management
Are my salespeople performing adequately? Are they balancing their time properly between closing deals and prospecting? How healthy is my sales pipeline? Which deals are they losing and why?
What products are different types of customers buying? What products do they buy together? What are our major competitors for each product line, and in what situations do they win? Why do some products receive more customer service inquiries than others?
How does my issue load vary over time? How does staffing level impact my time to resolve issues? Is the number of interactions or escalations decreasing over time?
What lead sources have been most productive in the past? What are the profiles of successful leads? What types of marketing activities drive the most interest?
In addition to providing a static set of measures to monitor the ongoing health and performance of the business, the CRM program can play an active role in business planning.
The recent rise in usage and importance of social media tools can make CRM an even more useful platform for learning about customers and informing business decisions. As more customers share their opinions, needs, likes, and dislikes via tools such as blogs, Facebook, and Twitter, more of this data can be incorporated to enrich the profile of your customer and market stored in your CRM application. Many tools and services exist today to mine this information and incorporate it into your CRM application. In addition to this passive information-gathering role, these social media tools can also be use actively by your organization to open up new communication channels with customers, using the tools they are already using and prefer. These new channels can be used to provide updates from the company, deliver promotions, and gather feedback.
Preparing Your Organization for Change
Preparing your organization for change prior to undertaking a new CRM initiative is an important contributor to CRM success. Change, even for the better, is often met with resistance, as people have a level of comfort with their current processes.
Thoughtful preparation can break down this resistance and help employees see the positive in the change and roll with the inevitable hiccups associated with new processes and applications. So how does one properly setup their organization for change? The main components that in our experience have proven successful include:
Data-Driven Culture
Pursuing a data-driven culture means documenting processes, gathering data on their effectiveness, making changes based on the data, and then evaluating the success of the change based on data. The entire process should be communicated to the extent feasible. This approach to change will help employees understand how situations are identified for potential change, how changes are developed, and how the effectiveness of those changes is measured. This kind of methodical approach inspires confidence that changes are not arbitrary; they are made with important business goals in mind, and they will be critically evaluated for success. The result will be an employee community more comfortable with change and more willing to support it. Obviously part of the purpose of your CRM initiate is to establish a framework for a data-driven culture - but to the extent possible fostering this culture prior to launching your CRM program will be beneficial.
Executive support
Having executive support for the implementation as a whole and specifically for the changes it will bring is imperative to a successful initiative. Executive(s) need to be involved enough to be able to guide decisions, and communicate the vision of the implementation project and its intended benefits.
Communication
Communication is important so that people know what to expect, which helps them prepare for the coming changes. It's important to start with a communication plan similar to that in Figure 1-1 that identifies who needs what information and when, how they are able to give feedback, who owns delivering the communication, and what channel will be used.
Training
Obviously training is a part of any technology implementation; however it is important to note that there are a few key things to consider when planning your program. Training early and often helps employees acclimate to the new technology and processes which reduces resistance.
Feedback
It is essential that people have a way to provide input into how their lives are impacted, positively or negatively, by a new technology/process. You will of course not be able to address each item of feedback (or in the way that the individual might prefer), however the very fact that it has been acknowledged, considered, and explained in a very honest way will go a long ways in having employees embrace the changes.
Recognition
Recognizing those that are properly utilizing the CRM system in the course of their responsibilities provides a positive example to others. This not only rewards the desired behavior, but it can show the benefit that those people are gaining in their job responsibilities (time, reduced data entry, etc.) Some good ways to recognize individuals include an email from the project "champion" to the team, small incentive rewards (i.e. gift cards), and special mentions in team meetings.
THEME 2. CRM HISTORY AND THEORY
3 THEME. CRM OPERATION SYSTEM ORGANOZATION
A successful CRM program provides the platform that helps your organization continually improve and refine the way it acquires and services customers. The increasing competitiveness of the business world rewards organizations that understand their customers and that can react quickly to seize opportunities and address challenges.
It's important to emphasize our use of the term program; success with CRM requires much more than just purchasing a CRM application and installing it. The heart of a CRM program is the continual examination and evolution of your customer interactions in order to provide better customer experiences and help your organization achieve its customer-related goals. The CRM application itself is simply the tool used to deliver great customer experiences, streamline your customer-facing operations, and gain insight into your customers and business.
Success with a CRM program is built on four pillars: having the right people in the organization engaged in the right roles in the CRM program, implementing well- designed internal and customer-facing processes, implementing the right supporting technology, and setting reasonable expectations for what success looks like and what kind of effort and cost are required to achieve it. Let's consider each component in turn.
Your CRM program will require a number of people from different parts of the organization playing different roles. lob titles and requirements will depend on the organization, but for most organizations, the following roles should be assigned for a successful CRM implementation.
The executive sponsor is the senior executive who is ultimately accountable for the success of the CRM program within your organization and is responsible for the following:
• Securing necessary funding for the CRM program.
• Guiding the ongoing CRM roadmap development process to ensure that the roadmap is well aligned with the organization's strategic goals. Roadmap development is described in detail in
• Ensuring engagement at the executive level from the different groups within the organization that need to contribute to the CRM program.
• Setting goals for the CRM program and holding individuals and teams accountable.
• Being the ultimate decision maker for CRM questions within the organization.
Important qualifications for a CRM executive sponsor include the following:
• Must be a CRM "believer." His or her tone, engagement level, and enthusiasm all have an outsized influence on the CRM program.
• Should be experienced with the people and processes in the customer-facing part of the organization. A finance or IT executive is not the ideal person for this role.
Employees follow their leaders; the executive sponsor's frequent, vocal, enthusiastic focus on CRM will communicate to the entire organization that CRM is part of its "DNA" and that each employee needs to make sure it is given priority. In addition to this evangelism, executives also need to hold each layer of management accountable for the success of CRM in their departments.
The steering committee is the critical body for guiding the CRM program within your organization. It should be chaired by your executive sponsor and include representatives from all the key CRM constituent groups (for example, inside sales, field sales, customer service, and marketing) as well as from IT and from the CRM administration team (described in a moment). The committee should meet regularly; your situation will dictate the appropriate frequency.
THEME 4.CRM PROJECT MANAGEMENT
The steering committee's responsibilities include the following:
• Managing the ongoing change control process for production CRM applications. This is the formal evaluation and approval process for configuration changes to the CRM application, used once CRM is in production to ensure that proposed changes do not interfere with any group's usage of CRM and that they are aligned with the overall CRM roadmap and to communicate these changes to the various CRM constituencies. Developing and implementing a change control process is described in Chapter 6.
• Developing and maintaining the CRM roadmap for the organization. The roadmap describes the plan for enhancing the CRM program over time and how these enhancements support the organization's strategic goals. The roadmap may describe new capabilities to be added to CRM, new user groups to be migrated to the application, or new business processes to be implemented and supported with CRM. Roadmap development is covered in detail in Chapter 3.
• Planning budget requirements for CRM, based on the roadmap.
Important qualifications for CRM steering committee members include the following:
• They can accurately represent the needs of their constituency to the steering committee.
• They can understand how changes to the CRM program raised in the steering committee will impact their constituency.
• They can dedicate the time needed to participate fully in the activities of the committee.
The IT representative can help inform the committee of planned IT initiatives that may impact the CRM program, as well as coordinate the support provided by the IT organization for the CRM application. This role is less critical for software-as-a- service applications, because the IT department's responsibility for these applications is typically small or nonexistent, and it is more critical for on-premises CRM applications.
The CRM administration team manages the execution of the CRM roadmap, the enhancement of the CRM application, and the training and support of users. They are typically the application experts and can help identify how the application can be used to help achieve a business goal identified by the steering committee.
The composition of the implementation team, charged with the initial rollout of your CRM program, will vary according to the complexity of your organization and the initial implementation project. In this section, we'll describe the key roles on the implementation team; in many cases, a single individual may play multiple roles.
The role of the sponsor was described earlier, and as for the overall CRM program, this person is also responsible for the success of the initial implementation. Typically the sponsor will want to stay current on the status and progress of the project and assist the implementation
team by clearing bureaucratic obstacles and encouraging engagement across the company to help support the success of the implementation.
The initial CRM implementation is a complex undertaking, requiring input from numerous departments and potentially changing behaviors and processes for all of the organization's customer-facing employees. A dedicated project manager is key to plan the project, keep it on schedule, and maintain communication throughout.
The subject-matter experts (SMEs) are the individuals on the team with a deep understanding of the business areas that will be impacted by CRM and will help guide the process design and CRM application design to meet the project goals. For a sales-focused project, for example, the SME team might include the director of sales, an experienced field sales representative, and an experienced inside-sales representative. It is important that the SMEs understand the situation "on the ground" today (what the current processes and what tools are being used) as well as the larger picture - the longer-term organization vision for CRM in their area, and the immediate project goals that help achieve the vision.
Some organizations have a tendency to want to leave the individual user/contributor (for example, the salesperson in the earlier example) out of the process, either because of fears of losing their productivity by taking their time with the project or because of fears that they can't think "big picture" enough to contribute. In our experience, this is a serious risk. Oftentimes, especially in larger organizations, executives do not have a sufficient grasp of how things actually work at the lower levels of the organization, where customer interactions actually occur. If they provide the only voice to inform the process and application design, you may end up with a gap between today's process and tools and the new CRM solution that is too broad to be bridged.
Typically the rollout of a CRM program includes a significant technology component: a new CRM application, a set of modifications to an existing CRM application, new application integrations to streamline operations, or new reporting and analytics tools. For this reason, it's important to include the IT department on the project team. Their responsibility on the project may be to procure and maintain server hardware, update client machines, assist the consulting team with network and server access, and potentially do some development and testing work. For on- premises deployments, the IT organization will also be responsible for disaster recovery planning and application backup.
A significant component of the initial CRM implementation project is user training. Trainers on the project team need to communicate to users how their work processes are changing as part of the project and how the new technology tools should be used to support these new processes. Some organizations have dedicated training departments, and others pull their trainers from the departments being trained; often the SMEs on the implementation team end up playing the role of trainer for their groups.
"Champions" are the point people within each group of employees impacted by CRM. Typically they have received additional training and potentially been involved in the design process and are charged with helping drive the success and adoption of the CRM processes and tools in their groups. Champions act as first-line user support for the CRM application and for the CRM-related process and as the eyes and ears of the CRM implementation team postlaunch to spot friction points and issues. They also have a key role to play in "evangelizing" the new processes and tools.
If you have engaged a consulting partner to assist you, their project lead and project consultants will have key roles to play during the implementation. Typically the partner project lead and your organization's project manager will work hand in hand to manage the project.
The champions, described briefly earlier, are a set of individuals working within the groups of the organization involved in customer processes who act as an ongoing conduit between the group and the CRM steering committee and CRM administration teams.
These champions add tremendous value in the following ways to your CRM program:
• Help with training and mentorship of employees, including communicating best practices around the use of the CRM application
• Communicate process and application feedback from employees in their group to the CRM steering committee and/or administration team
• Be vocal supporters of CRM; for this reason, it is useful to select people who are perceived as leaders in their departments
Champions act as the CRM program's "eyes and ears" within their department. They see how the application is actually used in practice by customer-facing employees and therefore what is working well and what is not working well. They are a great source of process and application improvement ideas and can alert the larger CRM team when plans are being made based on faulty assumptions of how processes work. They also play an important role in preparing their departments for process and application changes.
The CRM administration team is charged with two missions. The first is the ongoing, regular maintenance of the CRM program; this includes a variety of tasks, such as the following:
• Providing end-user support for the CRM application. Sometimes there is a centralized help desk within the IT department that may provide basic, "tier-one" support, but even in these situations, the CRM administration team has a support role to play as an escalation point for more complex issues. There may also be regular tasks that are more complex and that users require assistance with, such as data loads, mass e-mails, and complex queries.
• Maintaining the health of the CRM application. Again, depending on the structure of your IT organization, some tasks may be handled outside the CRM administration team, but they include applying software updates to the CRM application and the underlying operating system and database software, ensuring that the application is being backed up regularly both on-site and off- site, and preparing and practicing for disaster recovery. These tasks are not needed if you are using a software-as-a-service application.
• Administering users within the CRM application, including creating accounts for new employees, deactivating departing employees, and adjusting security access as employees move between groups or change roles.
The second mission is to identify, plan, and implement enhancements to the CRM processes and application. These enhancements may be identified by users and addressed as part of the regular CRM change control process outlined in Chapter 6, or they may be part of the CRM roadmap. The CRM roadmap is the phased plan for the development of the CRM program, which is always evolving. How to develop and maintain a CRM roadmap is covered in the next chapter. These enhancements can range from relatively minor in scope (adding fields to an object in the CRM application or automating an e-mail communication to smooth a transition from one team to another in a process) or significant such as bringing a new department into the CRM program.
Some of the following roles may be held by members of the IT department. If not, especially if your CRM application is hosted by your own company, there should be some representation from the IT department on the CRM administration team, even if it is simply as "virtual" team members who are kept in the loop about the work of the CRM administration team.
The CRM program lead is the overall project manager and orchestrator for the CRM program. This individual manages both the regular maintenance of CRM, as well as the enhancement processes (regular change control and roadmap execution). Key skills of this individual include the following:
• Strong project management skills
• Understanding of customer-facing part of the organization and empathy for customer-facing employees
• Ability to communicate comfortably at the executive level
• Experience with managing technology systems, vendors, and software developers
The role of the CRM business analyst is to combine three strands of understanding to help define a future state in which the organization is more effective and achieving its business goals. The first understanding is how employees work today, the second is what the organization's CRM goals are, and the third is a deep understanding of how the CRM application can be configured and customized. Combining these, the business analyst can outline how a given work process and the supporting CRM application can be modified to make the organization more successful. Key skills of the CRM business analyst include the following:
• Experience with process design/reengineering
• Experience with requirements gathering for technology systems
• Experience developing functional specifications for software applications
• Deep understanding of and experience with your chosen CRM application
• Deep understanding of the business processes supported by your CRM application
The CRM administrator is the central figure in maintaining and modifying the CRM application and, with the exception of the CRM developer described next, is typically the most technical member of the CRM administration team. This individual handles user support issues, maintains the application health, handles user management, and makes configuration changes as needed. In addition, this person typically manages data imports and the installation of any product add-ons. Key skills of the CRM administrator include the following:
• Experience administering an enterprise database-based application (required for on-premises CRM only)
• Deep understanding of and experience with your chosen CRM application
Most CRM applications can be modified in limited ways via a set of configuration tools that do not require deep technical skills. However, in most cases, implementing custom business logic to support your organization's specific business processes, building integrations to other applications, or developing highly customized reports all require programming. For this reason, organizations with significant complexity should consider having a software developer on the CRM administration team.
The specific skills and experience needed will be determined by your organization's choice of CRM application.
Training is an ongoing process within your CRM program. New employees join the organization, and enhancements to both CRM processes and applications necessitate ongoing training for existing employees. Typically this training is handled within the department, often by the departmental champions described earlier. However, larger organizations may include a trainer as part of the CRM administration team. These dedicated trainers collaborate with the departmental champions to develop training materials and curriculum. Significant application or process changes may also require the CRM administration team to step in and provide training to employees rather than have training handled within the department.
THEME 5. MANAGEMENT OF CONSUMERS’ LIFECIRCLE
We will address the topic of CRM processes in two parts. The first part will discuss the operational processes that your organization has implemented within your customer-facing departments. These are always a focus of CRM programs; organizations embark on CRM programs to produce a set of customer-related outcomes, and the CRM program improves or reinvents their business processes to achieve these outcomes. The second part will review the new processes to be put into place to manage the CRM program itself, specifically, ongoing maintenance and enhancement processes.
Every organization and its processes are unique, which prevents us from offering specific templates or guidance for what your own operational processes should look like or what changes should be made. However, in our experience, assisting clients in establishing and executing CRM programs, we have observed and can describe common categories of process improvement that appear over and over again as objectives of CRM programs.
Provide Metrics and Visibility to Customer Operations
Many organizations lack a well-designed approach to recording information about customer interactions in such a way that the information is broadly visible and actionable. Everything is handled in e-mail or in monthly reports that are arduously created, reviewed once, and then tossed into a folder somewhere. There is no platform for systematic information gathering. Running an organization of any size this way is analogous to flying a plane without any instruments. You are operating on anecdote and "feel" and have little ability to forecast the future or learn from the past. There is no way to judge the impact of procedure changes or new investments. Just as you can fly an airplane more effectively with a set of instruments that provide information on how the aircraft is performing, you can manage your organization more effectively if it too is "instrumented." CRM applications can be thought of as a way to implement an instrumentation platform for your customer-facing processes that allows you to define key metrics and then capture the data to provide this metric as part of your business processes. This ability to drive metrics and gain visibility into operations is an important motivation for many organizations to embark on CRM programs.
A simple example may help ground some of this theoretical discussion of metrics and process:
Consider an organization weighing an investment in a vertical marketing. Unfortunately, the organization has only anecdotal information about its customers' market sectors and therefore no quantitative understanding of what markets to target and what products to emphasize in each market.
Recognizing this, the CRM team makes the following adjustments:
1. It creates an attribute in the CRM application to categorize customers and prospects by market sector.
2. It modifies the inside sales team's qualification process to include capturing a prospect's market sector and entering the information into CRM.
3. It asks the account manager team to update CRM and enter the market sector for each of their customers.
4. It modifies the customer service team's issue creation process to include a check to see whether CRM contains the customer's market sector and, if not, to collect it.
5. It creates a report that breaks down customers, prospects, and opportunities by market sector and illustrates the average deal size and product mix in each market sector.
After 60 days, the report provides actionable insight into which markets drive the most revenue for the organization and which products are most successful in each market sector. This information allows the marketing team to craft a vertical marketing strategy with a maximum chance for success.
This example highlights the power of CRM to "instrument" the organization and collect information to answer meaningful business data—through a combination of people, processes, and technology.
Improve Customer "Handoffs" Between Departments
Botched customer handoffs are all too common and can result in lost revenue and a poor customer experience. Two examples highlight what we mean by a poor handoff:
Example 1: Passing a qualified sales lead from inside sales/marketing to a field sales representative
In many organizations, initial lead qualification is completed by the marketing or inside-sales departments; only well-qualified leads are passed to the field sales team. Often this handoff is accomplished over e-mail, and there are many ways that this can be botched; if the field sales rep is on vacation, is having e-mail problems, or simply overlooks the e-mail, the lead can get dropped. The inside-sales person has no visibility into what has happened to it after handing it off.
Example 2: Escalating a support issue
Large support organizations are often segmented into tiers; issues are funneled through increasingly experienced and specialized support representatives to make the best use of each individual's capabilities. In this model, a customer may end up speaking with two or three different representatives to work an issue through to resolution. In many situations, this hand-off from one representative to the next tier is a "cold" one, meaning the new rep receives no context about the issue before interacting with the customer, forcing them to explain their issue from the beginning to each successive representative. This is a frustrating and inefficient process for the customer.
CRM applications can potentially improve the handoffs in your organization.
• Example 1: CRM workflow automation can keep items from "falling through the cracks." Following a handoff, a certain period of inactivity can trigger a reassignment or e-mail notification.
• Example 2: Having your customer-facing employees all working in the same CRM application makes it simpler to pass context with the handoff to ensure that the experience is as seamless as possible for the customer or prospect.
Implement and Enforce Structured Sales Methodology
CRM applications are ideally suited to helping implement a structured sales methodology. These methodologies include proven best practices, and CRM applications can guide salespeople to help them execute the methodology consistently. In addition, CRM can provide visibility to sales management of how well salespeople are following the methodology and how it is impacting sales performance. Detailed CRM analytics can help the organization customize and tune the methodology to further increase performance.
A typical challenge of marketing groups is to understand the revenue impact of their marketing spend so that they can allocate funds to programs that produce results and eliminate programs that do not. Disconnected marketing and sales systems prevent many organizations from being able to even catalog the marketing touches received by a given prospect that was successfully converted to a customer.
CRM applications not only can close the loop between sales and marketing teams, but they can be used to test different marketing approaches (for example, different direct mail pieces or list sources) and measure the result through the sales cycle.
For organizations whose customer information is spread across a number of systems, targeting customers and prospects for specific marketing messages, based on their purchase history, order volume, geography, web site activity, and so on, can be a prohibitively difficult data management task. Not only must the data all be brought together in a single environment for filtering, but a customer ID table must be developed and maintained to know that Account #245 in the accounting system is the same entity as Customer #8879 in the marketing database is the same entity as Visitor #98786 in the web site tracking application.
Centralizing customer information in a CRM application and building thoughtful integrations to other key applications such as accounting and your web site can facilitate this task. Having all the needed criteria for filtering and targeting marketing touches within CRM allows for more personalized marketing without a complex data manipulation effort to combine data from disparate applications.
Customer self-service is a rare initiative that offers the promise of simultaneously decreasing service costs and increasing customer satisfaction. A healthy self-service channel allows an organization to serve the same customer base with fewer customer
service staff and offers the customer a faster, more efficient service experience. For organizations with basic customer service tools, self-service is one of three common focus areas for CRM programs, the other two being the implementation of structured issue tracking and the development of a searchable knowledge base tool. Typically self-service is the third of these areas to be developed; first an organization wants to streamline its internal processes around issue management and seed its knowledge base and only then offer customers self-service options.
The most common way customer self-service is addressed within CRM programs is the deployment of a customer web portal. This is a secure web site where customers can log in and interact directly with the CRM application in a controlled manner, without the need for a customer service representative to assist them. Common tasks undertaken by customers within a customer web portal include searching the knowledge base for resolutions to issues; creating, viewing, or updating existing service issues; downloading support materials such as manuals and datasheets; and updating their profile information (addresses, phone numbers, and so on).
Hand in hand with implementing the structured customer service issue management processes that are often part of a CRM program are the development of policies around service escalations. Well-designed service departments and escalation policies can help strike a balance between providing a positive customer experience and controlling services costs and are especially critical for organizations for which required response and resolution times are spelled out in their customer contracts.
The robust workflow logic available in today's CRM applications facilitates compliance with escalation policies and can automate the assignment of issues within the service group and the related communications both within the group and with customers.
Many organizations find themselves again and again forced to make important business decisions without the benefit of solid customer data. They find either that they are not collecting the information that they need or that it is collected but is spread across so many groups and applications that it cannot be synthesized in a reasonable time or at a reasonable cost.
CRM applications can help in that they centralize customer information in a single place and include robust querying and reporting tools for analysis. For more complex needs, a fuller business intelligence program may be needed, for which CRM would be one data source of perhaps many, including financial accounting applications, service scheduling applications, or provisioning applications.
We encourage all organizations initiating a CRM program to include some focus on reporting and analytics. These are the primary ways that managers and executives interact with and realize value from the CRM application, and if these stakeholder groups are not satisfied with CRM, their engagement will suffer and jeopardize the success of the program.
While the prior section highlighted some common business process areas that organizations target for improvement as part of their CRM programs, this section will introduce the processes needed to maintain and evolve your CRM program. These CRM maintenance processes are covered in greater detail in CRM program support for employees can be broken out into business process support, CRM application support, and the intersection of the two.
Because the CRM program often includes redesigning customer-facing processes, the CRM team needs to be prepared to support employees with questions about the process steps and how to handle exceptions. Good documentation and training play obvious roles, but there will always be a need for process support.
CRM application support is like technical support for any business application: users have problems with the software, encounter error messages, or simply forget how to accomplish tasks within the application.
The intersection of these two categories of support is often neglected in training and documentation. As an example, you can train a user how to qualify a lead in the CRM application, but this is insufficient; they must also understand at what point in the process a lead is considered "qualified" and the actions that should be taken. The sales process may proscribe a set of customer meetings, and the CRM application training shows how to record a customer meeting, but should all customer meetings be entered into the CRM application? If not, which ones should be? What information must be entered for them? This explanation of how the CRM application should be used in the context of the business process is often omitted in CRM training.
Training is an ongoing component of your CRM program. As new employees join the organization, they need to be trained both on your customer-facing processes as well as on the use of the CRM application to support them. Existing employees need to receive additional training as processes are refined and enhancements are made to the application or when new software versions introduce significant changes. The administration team also benefits from regular application training, especially as new software versions are released.
Most training, couched as it is in business process, is developed and delivered within an employee's group, but the CRM administration team may have a role to play in generic application training.
THEME 6. CRM APPLICATIONS IN DIFFERENT ECONOMIC SYSTEMS
CRM Application Infrastructure Overview
At its heart, the CRM application is a database with which users interact via an application server, using a variety of different clients. Figure 2-1 provides an overview of a typical CRM application technology architecture.
|
Figure 1. Typical CRM application infrastructure |
The complexity of your CRM infrastructure will mirror the scale of your organization. Small CRM implementations may make do with a single physical server playing the roles of both application and database server. Enterprise CRM
deployments may have many servers to spread the load of large numbers of users and to provide redundancy to avoid system downtime, and their environment may include other hardware components such as network load balancers and dedicated storage appliances. Your consulting partner and IT team should work together to predict the CRM application usage in your environment and size your infrastructure accordingly. Consider your roadmap when making infrastructure decisions; if you scale your hardware to match your pilot user load, you may be very unhappy when you roll out the application to a much larger user community for production usage.
As part of the general trend in the technology industry toward cloud computing, most of the leading CRM application vendors now offer their products as a "software- as-a-service" or "cloud" application. In this model, the server components outlined in Figure 2-1 are owned and managed by the vendor, transparently. The application is purchased on a subscription basis and accessed over the Internet. If the application is accessed via a web browser, the customer does not need to install any software. The choice of deployment model (traditional on-premises vs. software-as-a-service) should be driven by a number of factors, including long-term cost, availability of IT support resources, sensitivity of the data to be stored, required level of customization and integration, and so on.
Production, Development, and Testing Environments
In addition to your production CRM application deployment, you will likely want to operate one or more additional CRM application deployments for development, testing, or training purposes.
Potentially as part of your initial CRM launch or down the road as your requirements mature, you may find the need to develop custom components for your CRM application, perhaps to add new features or to integrate with other business systems in your organization. Developing custom components inside your production environment is fraught with risk, and we strenuously advise against it. It can be disruptive to the production users, may cause system downtime or interruption, and may corrupt data.
Thorough testing is important to ensure that new custom components function as designed and that no existing functionality or processes are negatively impacted. Ideally, a third CRM environment, specifically for testing, would be used. This environment should match the production environment as closely as possible, with respect to hardware, software infrastructure versions, and so on, to provide a high level of confidence that custom components that perform well in testing will also perform once migrated to your production environment. Separating development and testing into separate environments is important; for any significant size of development effort, these two activities cannot really happen in the same environment. Testers need a stable, consistent environment running a known set of
code to do their work. They can't function if developers are constantly injecting newly written code into the system.
Larger organizations have a significant ongoing training need, and many will set up separate environments for this purpose. We have also seen testing and training share environments, but this can be confusing for trainees because they may see new feature work under development that does not yet exist in the production environment.
However many environments you intend to manage as part of your CRM program, it is time well spent to map out the steps for two important processes:
• Refresh development/test from production: Periodically, perhaps between development projects, you will want to sync your development and test environments with production so that they are again replicas of production. This ensures that these environments are not slowly drifting away from production, and it brings fresh data into the environments to assist in development and testing. The process should be well-documented, repeatable, and ideally not too onerous. Privacy policies may require some data from production (for example, Social Security numbers) or be omitted or obfuscated in development and test environments.
• Migrate custom components from development to test to production: It is valuable to document both the "process" and "technical" steps to migrate custom components from development to test to production. The process steps will likely be defined as part of your development methodology, with prescribed gates and quality bars for each environment. The "technical" steps to migrate custom components will vary depending on your CRM application.
Note that these processes may be significantly different depending on how your CRM application is deployed (hosted on the premises or via software-as-a-service), but regardless of your deployment model, the need for nonproduction environments and the ability to execute these two processes both exist.
Most CRM deployments can benefit from and ought to be using some form of source- code control to manage configurations and custom components. The advantages of using source control are great, and the overhead is not nearly as significant as you might imagine. Managing any development effort with more than one developer will quickly break down without it. For nondevelopers, source-code control systems manage the source code for configurations and custom components (typically dozens to hundreds of small files) and provide the following benefits:
• Help prevent or manage collisions where different developers independently make changes to the same files
• Allow access to a history of file changes and reversion back to prior versions of files as needed
• Allow multiple versions of the software to be run to allow for branched development and help isolate bugs
There are several options for source-code control from a number of vendors, including some robust, no-cost, open source applications.
Common CRM Application Functionality
As an introduction to the CRM application space, in this section we'll outline common functionality found in leading CRM applications. This will provide a framework that will help you understand and evaluate different applications more quickly and effectively.
Customer records are the heart of the CRM application, around which most other information revolves. These are broken into "account" or "company" records to represent organizations that you interact with, and "contact" or "individual" records to represent individuals.
Key customer functionality to look for includes the following:
• The ability to add fields to categorize customers in multiple ways— by sales territory, by market segment, or by industry
• The ability to track multiple types of organizations, either using the customer record or using other records, such as partners, vendors, and prospects
• The ability to create multiple, ad hoc relationships to link accounts and contacts in order to represent the multitude of important relationships that might exist
• The ability to easily track interactions with customers such as meetings, phone calls, e-mails, and faxes
Marketing features are intended to help execute and track outbound marketing activity such as direct mail, e-mail blasts, and telesales call-downs. A critical factor is how well the marketing thread is persisted through to the sales area, to help tie revenues to marketing activities. This is a common challenge for marketing teams and one that CRM applications are well-suited to address.
Key marketing functionality to look for includes the following:
• The ability to manage suspect/prospect information independently from customers for qualification and marketing purposes
• The ability to develop lists using various criteria and then direct marketing activities against the lists
• The ability to organize marketing activities into campaigns for planning purposes
• The ability to execute direct e-mail campaigns in a robust way (for example, tracking e-mail opens, bounces, and forwards; using rich templates for e-mails; and managing the opt-in/opt-out process)
• The ability to tie sales and customer acquisition activity back to marketing efforts
The sales department is where CRM applications got their start (referred to as sales force automation [SFA] applications in the early days), and sales teams continue to be the primary driver for CRM initiatives. There are a number of motivations for bringing CRM applications and well-designed CRM processes to sales teams—the most popular include providing management with better visibility to sales activity and the sales pipeline, helping to support a structured sales methodology, and reducing administrative work and helping salespeople be more productive.
Key sales functionality to look for includes the following:
• The ability to manage sales opportunity information such as deal size, estimate close date, products/services being sold, and stage in the sales cycle
• The ability to define and manage a structured sales methodology
• The ability to create quotes for presentations to customers and prospects
• The ability to create a sales forecast for reporting to sales management
The customer service features of CRM applications are intended to help organizations record customer issues and effectively manage them through to resolution. Service processes are often among the most studied and structured in an organization, because of their significant impact on the customer experience and the desire to control costs in a department that is not traditionally a profit center.
Additional benefits of managing service processes within the CRM application include the following:
• Service staff members are often a source of potential follow-on business within existing accounts—by having service employees working in the same application as sales, handoffs between the teams can be streamlined, and workflow automation can prevent dropped leads.
• Service issue data is a rich trove of information that can be used to improve and refine the organization's products, services, and customer-facing processes. The easy linkage between service data and customer data allows for insight into the distribution of service-issue categories across customer segments.
Key service functionality to look for includes the following:
• The ability to manage and categorize service issues (often referred to as cases or trouble tickets). Information tracked for each issue may include the stage in the service process, issue type, related products/services, and issue owner.
• The ability to define and support multiple issue resolution processes for different categories of issues.
• The ability to support service queues to facilitate issue routing and resolution.
• The ability to deploy a self-service portal where customers can log in to create, update, and view service issues.
• An integrated wiki or other knowledge base tool to foster information sharing across the service department.
Although some organizations configure their CRM applications in an "open" manner—where each user can see all information in the application—many need to be able to compartmentalize information. Common examples include sales information, sensitive customer information such as Social Security numbers or account numbers, or even compensation or commission information. A robust security model within your CRM application will give you the flexibility to manage a wide range of different security scenarios.
Key security model functionality to look for includes the following:
• The ability to secure information at both the entity level (for example, accounts, contacts, sales opportunities) and the individual field level (for example, Social Security number)
• The ability to bundle permissions into "roles" that can be assigned to users or groups to facilitate user management
• The ability to handle security exceptions—for when a user needs access to a certain record or set of records outside their current scope of access within the application
• Security that is pervasive throughout the application—applies to viewing information through the user interface, any search or querying tools, and reports and dashboards
Configuration and Customization
CRM applications always require configuration and customization to deliver an elegant user experience and to maximize the value they can provide to your organization. Each organization is different, with different types of customer information to record and different business processes to support with its CRM application. When discussing changes to the CRM application, we use the term configuration to describe changes that can be made using the application's administrative tools and features, without programming, and customization to describe changing the application via programming. The extent and sophistication of a CRM application's configuration abilities and customization flexibility will determine to what extent you can tailor the application to your present and future needs, as well as the level of effort this tailoring will require.
Key configuration and customization functionality to look for includes the following:
• Ability to extend the application data model without programming. This includes adding new fields to preexisting entities (such as "customer" and "sales opportunity"), as well as designing new entities. These new entities that you define should be fully formed, with the same capabilities as the preexisting entities.
• Ability to insert custom business logic via code into the system to change the way it behaves, typically around system events (for example, the creation of a new customer record or the reassignment of a sales opportunity).
• Ability for other applications to interact with the CRM application. Does an application programming interface (API) exist for the application? How robust is it?
A large measure of the value of the CRM application is realized through the use of well-designed reports that provide business insight and enable informed decision making. For employees who do not interact with customers, the direct value of the CRM application may be exclusively that gained from CRM reports and dashboards. Don't put too much stock in the out-of-box reports—they are typically too generic to be useful without customization—but rather focus on the report generation tools and the accessibility of the data.
Key reporting functionality to look for includes the following:
• User-focused tools that enable construction of basic reports and dashboards without programming.
• Open access to the data using other reporting tools via standard protocols (for example, ODBC), in a way that respects the application's security model. For example, some applications allow data to be exported to Microsoft Excel for reporting and analysis.
If you consider that one of the key functions of your CRM application is to support your customer-facing business processes, the application's workflow automation features are an important focus area.
Without workflow automation, most CRM applications are fundamentally electronic filing cabinets—storing customer information in an organized, searchable way. This is valuable but positions the CRM application as a passive participant in any process—a place to retrieve and store information at various steps. It is workflow functionality, combined with custom logic applied to system events, that can make the CRM application an active participant in the process. A simple example may be useful to emphasize this difference: consider the case of the handoff of a qualified lead from marketing to the field sales force.
Passive CRM
The marketing rep enters the information from his qualification call onto the lead form. He judges that the lead meets the threshold of "qualified," and he manually reassigns it to the appropriate field sales rep and moves on to the next lead. In the field, sometime in the next few days, the field sales rep logs into CRM and navigates to the list of new leads assigned to her. She opens the lead and reaches out to set up an initial meeting.
Active CRM
The marketing rep enters the information from his qualification call onto the lead form. The CRM application notes that the lead meets the predefined qualification criteria—it automatically changes its status to qualified and reassigns it to the appropriate field sales rep based on the organization's territory sales model. It sends an e-mail to both the marketing rep and the field sales rep to announce the handoff. It starts a timer running; if the field sales rep has not updated the lead in two days, a reminder will be e-mailed to the field sales rep and her manager. In the field, the same day, the field sales rep opens the lead routing e-mail and follows a link in the message to read the marketing reps notes and find contact information for the lead. He reaches out to set up an initial meeting.
The difference should be clear. In the first example, the CRM application is just a repository, where in the second it is an active participant—taking actions and helping foster communications between team members. This type of capability is provided by the CRM application's workflow automation functionality. Key workflow functionality to look for includes the following:
• The ability to design multistep workflow processes that can respond to application events (for example, creation, update, deletion, reassignment of records) and take a variety of actions (for example, create new records, reassign records, send e-mails or text messages, update records). This should not require programming.
• The ability to branch and control the flow of the workflow process.
• The ability to extend workflow processes with custom logic via code.
Social Media and CRM Applications
Social media tools are emerging as a new communication channel that individuals are using to interact with one another and with organizations. This form of communication is different in significant ways from traditional channels, and organizations need to consider the opportunity it offers for customer engagement. We're defining social media here as tools such as Facebook, Twitter, blogs, wikis, review sites, and video sites that allow individuals to communicate, to create and exchange content, and to find others with similar interests or concerns.
One important aspect of the rise of social media tools is the power they grant individuals to sway public opinion. In the past, an organization needed to manage the opinions of a small set of critical journalists and industry analysts who had the outlets to reach a large audience with whatever message they chose to communicate about the organization. The rise of social media has given every individual the tools to broadly share their dissatisfaction or satisfaction and analysis of an organization. This has significantly complicated the task of the marketing and public relations teams charged with protecting and enhancing an organization's brand.
Social media tools also provide some interesting new capabilities for organizations. Gathering feedback on products and policies is easier and less expensive than with traditional methods (such as focus groups), as is engaging customers in the product planning and design process. Communicating organization updates via Facebook and Twitter reaches individuals in a manner that they are accustomed to and comfortable with.
How can CRM tools help manage an organization's social media presence and communications? Several products exist to provide these capabilities, often integrating with existing mainstream CRM suite applications. The capabilities offered typically include the following:
• Monitoring social media tools (Facebook, Twitter, review sites, blogs, and so on) for references to the organization and helping manage the organization response
• Managing and tracking activity for influential individuals who are widely followed and who publish statements or content about the organization
• Coordinating the organization's proactive communications via social media tools
• Linking an individual's CRM record with their profiles in various social networking sites to provide the CRM users with a fuller picture of the individual and their relationships.
THEME 7. CRM IN FINANCE
Depending on how your team functions internally, you may or may not be required to track expense items toward an internal budget. If you are using a vendor, you will definitely want to ensure you're tracking their spending toward your identified budget.
Budget management can be a tricky thing to manage because it is something that's easily gamed by the vendor. How you manage the budget and what tools you use to identify any budget risks is dependent on the kind or size of project you're undertaking.
If you are working on a small initial project, you may only have some spend associated with a kickoff and then some amount of fixed monthly spend moving forward. In situations like this, the important thing to track is spend against budget and the amount of work received on a monthly basis. That will be the key to allowing
you to define whether the monthly value meets or exceeds the amount spend, whether internal or external.
Should your team be focused on a larger project for the first phase of your CRM program, the costs are generally quite variable. Effort associated with a larger project can range from a few weeks to a couple of years, and literally everything in between. The tools you use to manage your budget can vary greatly; however, we will provide one example along with thoughts on the value of specific sections.
Total spend to budget tracking. This piece of the tool provides you with the ability to look at the total allotted budget and see how much has been spent. Depending on the status of the project, you may have to make some educated decisions about how much should be available, but ultimately, the data here will assist you with making that determination Remaining budget At any point in the project, you will have the availability to look at a single number and understand how much budget is remaining.
Weekly budget expenditures: Viewing weekly budget hours and spend is a very important piece to the budget management puzzle. First, this visibility allows you to overlay weekly spend with your project plan to ensure the two match. Second, this allows you to make the more important budget determination for big projects, such as how much budget remains and whether it is appropriately spread across the remainder of the project.
Invoice status: Project managers and vendor resources are often tasked with providing updates to invoicing status in addition to the classic budget. Using this template, you can provide the steering committee with dates and amounts of any invoices submitted by the vendor.
Project impacts and change request tracking Simple automation in this template can give you the ability to track project impacts and change requests in the same place as the original budget. By adding them to this spreadsheet, the overall budget number will increase, allowing the project management team to utilize the total budget number when evaluating budget status.
Overall budget status: By incorporating all of the items into the budget spreadsheet, you will be able to instantly tell what percent over or under budget the project is.
The larger the project, the more likely the risk that the budget will be spent inappropriately. In larger projects, there is a risk that the team will spend 80 percent of the budget to deliver 10 percent of the functionality. Once this happens, the implementation team is in a difficult position because they've made promises to the user community, but the costs continue to be significantly more than previously expected.
Ultimately, the most important thing for the project management team to understand is the status of the budget at any point in time. Whether that status relates to total spend, upcoming spend, or simply how many hours will be used during a current week, finding a mechanism to provide this information is key.
Issue Management
Although we may begin to sound repetitive, being prepared to manage issues is yet another important facet of planning the project. Much like parking lot items and status reports, having issues be transparent to users will go a long way toward allowing them to trust the implementation team. In addition to this potential value, managing issues is about accountability and risk.
To successfully manage issues throughout the life of a project, having a mechanism to track them, however simple, is important. This tool will also allow the core project team to manage the ownership of those issues to ensure the proper follow-up and triage by folks on the project team.
Regardless of the size of your project, you will have resources of some sort to manage. Like many of the activities associated with planning and managing the project, setting the appropriate expectations up front will enable you to be more successful in the long run.
If your focus is on internal resources, one mistake we frequently see is not allowing enough time for internal resources to complete tasks. Unless your organization is fortunate enough to have individuals who have worked on CRM projects in the past, many tasks will take longer than expected.
Typical Vendor Contracts
The type and format of contracts utilized by vendors vary greatly; however, there are two high-level types of documents that it may make sense to have between your organization and any vendors involved in the project.
The first document is typically called a professional services agreement (PSA) or master services agreement (MSA). The classic purpose for this document is to outline the terms and conditions governing the relationship between the two organizations. This document will be an umbrella document under which any project work is defined and completed.
The second normal document is often called a statement of work (SOW). This document is specific to a project and usually covers a project's scope, assumptions, deliverables, and individual project costs.
Throughout this book, we discuss the value of having an executive team that supports your overall CRM program. At this point, that focus should be on the specific project at hand.
Executive support at this point in the implementation can come from two primary sources: a single, high-level executive and the project steering committee. Whether focused on simply kicking off the project or on gaining alignment with the overall project team, the project charter document can be a tool to ensure the team is moving in the same, and correct, direction.
The project charter should be developed by members of the core project team. A number of the key charter items, such as risks, project schedule, and project dependencies, require input from various stakeholders and may not be known solely by the project manager. Looping in, and getting buy-off, from those involved in any risks or scheduling dependencies will ensure the project manager has the ability to effectively manage those issues should they arise during the project. After you have worked with the team to develop the charter, you should plan to roll it out to the whole team and solicit feedback. Figure 5-16 is an example of a project charter table of contents.
THEME 8. CRM AND DATA BASE
CRM reports are typically executed against the transactional database (the actual database used by the CRM application) or a separate database dedicated to reporting (often referred to as a data warehouse).
Reporting against the transactional database is the simplest approach; no data needs to be moved, and a separate database does not need to be maintained. However, there are several drawbacks to this approach:
• Limited or nonexistent time-series data: Information about how the data in your CRM application is changing over time is of potential business interest. However, reporting against the transactional database can provide only a snapshot of the data at the moment the report is executed. A data warehouse can accumulate trend data over time to answer questions that include a time dimension. For example, a transactional database report could answer the question "How large is my sales pipeline right now?" but not the question "How has the size of my sales pipeline changed in the last six months?"
• Limited on nonexistent ability to integrate additional data sources: Many reports need to draw information from multiple sources, including CRM, to provide a complete picture. CRM applications do not typically support importing data from other applications into their databases for reporting purposes.
Selecting whether to use the transactional database or a data warehouse for CRM reporting is, like most decisions associated with a CRM project, a balance of business value, cost, risk, and complexity.
Several categories of reporting tools are available for CRM, for different purposes and with different characteristics. You may end up using a combination of tools to meet your reporting needs.
These tools excel at developing fairly static reports that are run regularly to address a recurring set of business questions and that are presented to decision makers. They typically yield visually appealing reports but with limited flexibility without changing the programming of the report and limited or no interactivity. Dashboard reports are specific, graphics-intensive versions of these reports.
Typically CRM applications include some basic presentation reporting tools that retrieve data from the transactional database as part of the application.
If presentation reporting tools are all about displaying the answers to predetermined business questions, data analysis tools are about exploring data to uncover trends and diagnose business issues without a specific question in mind. These tools predictably put less emphasis on a polished final result but include features to let an analyst filter and segment data, experiment with different visualizations, and perform statistical analysis.
Data analysis tools are not typically offered by CRM vendors and must be procured separately from business intelligence software vendors
Report design is ideally an iterative, collaborative process involving the business users, business analysts, and report developers. Central to the design process is the report specification document, which describes the functioning of the report and acts as the touch point of the process and ensures that everyone is on the same page.
There are a number of styles and variations of report specifications, but most will address the topics in Figure 6-10.
Given the tight budgets associated with CRM projects, it may be tempting to neglect training for reporting. There are several reasons why this is likely a mistake:
• Even if the report technology is simple and intuitive, training is typically needed on the data. Users need to understand what it means, where it came from, and how it was filtered on its way to the report. If the report includes complex calculations, these need to be spelled out for users. This information is critical to the user developing the trust in the report needed for the report to drive decision making.
• Report users are often senior executives who have a significant influence on the CRM program. Their satisfaction and enthusiasm are important to the success of the program and merit a training effort to ensure their experience is positive.
• Unlike presentation reports and dashboards, data analysis tools are complex software packages that require training to use effectively. You may consider sending your business analysts to specialized application training with your analysis tool vendor.
Data migration refers to the programmatic duplication of data from one application or system to another. It's an important element of many CRM projects. Consider an organization implementing a new CRM application: once the software is installed, the application is essentially empty. It contains no customer account, contact, or lead information. This information would have to be entered manually by the users as needed, gradually populating the CRM database, which is an arduous, inefficient, frustrating process. But most often an existing application has this customer information; perhaps it's an older CRM application that is being retired. A data migration effort uses software tools to copy this information from this existing application into the new CRM application so that when users start working in the new CRM application, most of their data is already there. This allows users to start productive work with a minimum of data entry of basic information and to have access to important historical information about their customers and prospects without having to refer to the retired application.
Data migration is not limited to new CRM implementation projects. As an example, an organization might want to retire an existing, stand-alone customer service application and expand their sales-focused CRM application to encompass the service functions. This project would likely involve a migration of customer and service history information from the service application into the CRM application so that service users could easily start using CRM to manage their work.
A well-executed data migration can be tremendously valuable, helping users make a smooth transition to a new application and saving countless hours of manual data entry. In cases with large data sets, data migration is the only practical way to populate the new application. However, data migration is often difficult, expensive, and imperfect. In this section, we will provide guidance on how to evaluate whether data migration makes sense for a given project and, if so, how to plan and execute a data migration effort.
Do You Need Data Migration for Your Project?
Because of the difficulty and expense associated with data migration, the sensible default is to not include it in the project and to add it only after careful consideration proves its merit. The business value of having the data in CRM must balance the effort to migrate it. Evaluate the following factors to determine whether a data migration is warranted:
• Does the relevant data exist in a structured format of some kind? Data migration can be accomplished from databases, spreadsheets, and other structured applications but is typically not feasible from unstructured data such as e-mail How complex is the data? Multiple relationships within the data, free-form notes, and file attachments all complicate the migration.
• Size of the data set. For small, simple data sets, it may be more cost effective to have either users or temporary staff manually reenter data into the new application vs. executing a programmatic data migration.
• Availability of prior application post-project. If the source application is not being retired or can be made available post- project, it may make sense to not migrate data that will only occasionally be referred to by users.
Quality of the data. If the data quality is sufficiently poor, it may be less effort to start from scratch than to migrate and then clean the data.
Each data source (that is, application or database) being considered for migration must be examined from a number of different perspectives, both to enable a decision about whether to migrate it and to be able to design and execute the migration.
The first hurdle to be overcome is data access; your data migration tool must be able to programmatically access the source application's data. Often there is a straightforward solution; data migration tools come packaged with "connectors" that allow them to easily connect to popular source applications. Or if the source application stores its data in a standard database (for example, SQL Server, MySQL, Oracle), most data migration tools can access it without difficulty. For data sources with obscure or proprietary data storage, data can often be accessed via some kind of export utility within the application, which will output the data into a standard format that can then be read by your data migration tool. If this is the case, it is important to make sure that this export feature includes the unique record identifiers used by the application to link records to one another (e.g., a contact record to its parent account record). If your data source uses a proprietary data storage format and does not include a usable export feature, your best bet may be to engage the application vendor's help in accessing the data.
Once you can access the data, the real work begins. You must understand the structure of the data so that you can design your data migration process to copy the important data and preserve the relationships between the different types of data. Some applications have documentation, often as part of their software developer kit (SDK), that describes the data schema. If you are using an application's data export feature, this work is greatly simplified because you will typically export data one business entity at a time. If not, you will need to be a bit of a detective to decode the application schema. You are trying to determine, for each business entity (that is, account, sales opportunity), in which columns and tables the data is stored and how the relationships between different business entities are managed. Users of the application will be able to help by showing you how to navigate the application interface and highlighting what data is important and must be part of the migration, but they are not typically familiar with the data schema of the application. Selecting a few records of each type and switching between viewing the records via the application interface and within the data itself will typically illuminate the schema to a sufficient degree to enable the migration.
Several categories of data quality issues can dramatically increase the difficulty of data migration. Inconsistent application usage is perhaps the most prevalent; this may manifest itself as different users using the same application field to store different information, as well as different users using different interpretations of application terms (for example, one user would rate a particular lead as "qualified" where another would rate the same lead as "unqualified"), as well as simple intermittent usage (for example, only a subset of users ever bother to enter their prospect's mailing address). Other issues are straightforward but can take significant effort. For example, for free-text country fields in which some users have entered "United States," others "USA," others "U.S.A.," others "US," all variations must be handled by the data migration process. Spot-checking records, user interviews, and database queries can help assess the quality of the data in a source to determine the value of migrating it into the CRM application.
It is important to note as well that data quality can vary within a single application. For example, customer information may be rigorously maintained and updated, where lead information is used only by a small number of users with sloppy data entry habits and little standardization.
If possible, it is preferable to address quality problems first, independently of data migration. A common expression, "garbage in, garbage out," is often used to describe the fact that if the data fed into the migration process is of poor quality, then your CRM application will be populated with poor-quality data. Data migration does not solve data quality problems.
Designing the data migration has two parts. The first is a functional design, which describes what types of data will be migrated (by business entity, such as "accounts," "contacts," "service tickets"), which records of each type will be migrated (all, the last six months, or active records only?), and for each type, how the data will be mapped to the CRM application. The technical design describes how the migration will be accomplished, and its structure will be driven by the choice of migration tool. The technical design is outside the scope of this book; in this section, we will focus on the functional migration design.
Each source application that will be part of your data migration will require its own functional and technical design.
Data migration design, like application design (described earlier in this chapter), is a time-intensive process that requires participation of the project team members who understand the source applications and how they are used, as well as the finalized CRM application design.
Functional Design: Which Data to Migrate?
The project stakeholders and subject-matter experts familiar with the source application should be well equipped to provide guidance on the important business data managed by the application and what must be brought forward into CRM to meet the objectives of the project. The flip answer to this question that you may hear is "All of it, of course." In truth, each business entity added to the migration increases cost and complexity, and it is rare that all of the data in an application provides enough value to merit its inclusion in a migration process.
Functional Design: Which Records of Each Type?
The volume of data to be migrated impacts the cost and complexity of the data migration process. It can significantly increase the time needed to develop, test, and execute the migration. For each type of data identified as being part of the migration, consider whether the entire data set needs to be migrated or whether a subset is most valuable. In the example of migrating from one CRM application to another, you might ask yourself , "Do I need records of telephone calls with customers that happened over five years ago?" or "Are leads that have not been updated in more than two years really valuable?"
Once you have identified the data types and the records within each type to be migrated, the next step is to document how the data will be mapped. This mapping is done at three levels, as described in the following sections.
Entity Mapping
Entity mapping is the highest-level mapping, where each type of source application data is mapped to a corresponding CRM business entity, based on the intent of the entity and the functionality it provides. Typically this mapping is straightforward and intuitive, but there can be mappings that require more consideration. For example perhaps the source system has an entity called "Sales Call," where the destination has entities for "Meeting" and "Phone Call." A decision must be made as to where the Sales Call records will be mapped. Perhaps most of these represent physical meetings, in which case the decision might be made to map them to Meetings. Or perhaps there is a flag on the Sales Call to indicate whether the Sales Call was in- person or via phone, and this information is used to determine for each Sales Call whether to create a Meeting or a Phone Call
Field Mapping
Once the entity mapping is complete, you can proceed to the field-level mapping. This exercise consists of identifying, for each entity to be migrated from the source application, each data field to migrate and into which CRM field the data should be inserted. Ideally these mappings are simple; just take the value from field ABC in the source application, and insert it into field XYZ in the CRM application. However, as the quality of the data in the source application goes down, complexity begins to creep into the field mappings. Consider the case where some users in the source application put a certain piece of data in field ABC, while other users put the same data into field DEF. Now instead of a simple field-to-field mapping, you instead need to insert some logic, such as "look in field ABC first; if it is empty, then look in field DEF, and take the resulting information and copy it to field XYZ in the CRM application." And how do you decide what to do if a record in the source has data in both field ABC and field DEF? Ideally, you are starting to get a sense of why data migration can be such a difficult, imprecise, and expensive undertaking. Record ownership mapping is another complex element of the data migration. How should records belonging to former employees in the old application be assigned in the new application? Should you create user records for the former employees in the new application to try to preserve the
record history, or should they all be reassigned to a current employee as part of the migration?
The field mappings can be documented by expanding Table 6-4
Value Mapping
The final level of the mapping exercise is the value level. This is where we identify, for each row in our field mapping table, any transformation that needs to be made to the data in the source application before it is copied to the CRM application. Some examples of these "transformations" include the following.
This transformation is almost always required when mapping to a pick-list field in the CRM application. A pick-list field, also known as a drop-down list box or simply a list box, is a type of field where the user entering the information can select a single value from a limited set of options. The transformation is required for a couple of reasons. First, the contents of the fields to be mapped may not contain exactly the same values. For example, consider a field on a sales opportunity record to track the sales stage of the opportunity. In the old CRM application that is the source, the available
options are "New," "In-Progress," "In-Contracts," "Won," and "Lost." However, the new CRM application includes a new sales methodology, with stages of "New," "Qualified," "Developing Solution," "Negotiations," "Won," and "Lost." In order to copy a sales opportunity from the source application to the new CRM application, we must define how the values for the sales stage from the source application should get translated to the CRM application. This definition requires input from the project team that is familiar with the source application and its data and the new CRM application design. These mapping can be documented by expanding the format of Table 6-5 to include field values Even if the values line up perfectly for a given field between the source application and the new CRM application, a value mapping is likely needed. Applications typically do not store the actual text that we see in list boxes but rather a numeric code. So, for example, rather than store the word New in the database for an opportunity's sales stage, the application will store "3," which is the number associated with the word New. However, the CRM application likely has a different numeric code for "New," perhaps an "8." So even though the text options for the pick lists are the same between the two applications, we must change the "3" to an "8" when we copy it from the sales-stage field in the source application to the sales-stage field in the CRM application.
Some fields require a data lookup to map from the source application to CRM. Consider, as an example, the "Sales Rep" field on the sales opportunity. The value in this field represents the salesperson who owns the opportunity. This field is typically a link to the appropriate record in a separate table of users within the source application. The migration process must take the value from the source application's sales opportunity table, look up the salesperson in this user table using this value, and then find the appropriate user value for that individual in CRM and enter their value in the appropriate CRM field.
Different applications handle the same information in different ways; this can lead to the need to parse data as part of the data migration process. For example, consider a scenario where your source application stores an individual's name in a single field, called "name," but your CRM application has separate fields for each component of the name (for example, "first name," "middle name," and "last name"). The data migration process must somehow split the source data into its individual parts and pass the right part to the right field in CRM.
This is an example of where data migration can get messy and imprecise. While algorithms to break up names, as needed in the previous example, are good, they are not perfect and can make mistakes when presented with "Dr. Sally Brown" or "William Van Winkle." Is "Van" the middle name or part of the last name?
Data Migration Design Sign-Off
Once the data migration design is complete and documented, a formal sign-off by your team is important. This is an accountability point, and the team should understand that they are acknowledging they have reviewed and considered the design and that they believe it meets the business need. Data migration design is a detail-oriented task that requires patience. Time invested here is well spent, because changing the design once the process is built can require extensive rework and cost.
Data migration can be accomplished using a variety of technology tools; in-depth coverage of these is outside the scope of this book. In this section, we will provide an overview of the two primary approaches, as well as some of the advantages and disadvantages of each.
Purpose-Built Application Data Migration Tools
A number of products are available that have been built specifically to help businesses migrate data in and out of enterprise applications such as CRM. These products have a number of compelling advantages that make them the best choice in most situations:
• Migrations are designed and executed via a user interface; no programming experience is required.
• Prebuilt connectors to popular applications can make setting up a basic migration very quick and easy if a connector is available for your application.
• They have a rich set of functions to easily perform data transformation as part of the data migration.
These applications can typically be licensed on a permanent basis for ongoing application integration (which requires similar tools as data integration) or on a temporary basis for a one-time data migration. Typically the developer or consultant time that is saved via the use of an off-the-shelf data migration tool far outweighs its license cost.
The other approach to data migration is to build your own migration application, either from scratch or using a platform technology such as Microsoft SQL Server Integration Services. If you have the development expertise available, this approach yields maximum flexibility and may be the only viable approach in unusual circumstances with uncommon data sources or special performance requirements.
However, it is far more labor-intensive than using an off-the-shelf data migration tool. Your developer will need to ramp up on the data schema or interface for the source application (to understand how to read data), as well as the interface for the CRM application (to successfully write the data from the source application). All of the logic that comes built into the off-the-shelf product, such as error handling, logging, transformation functions, may need to be written from scratch.
Testing the Data Migration: The Mock Migration
During the data migration development, your team will likely run a number of small migrations in your test environments to refine their migration process and spot problems. It is important, however, that at least one migration be executed with the full data set to be migrated. This "mock migration" acts as a test of the migration process, a gauge of migration performance and timing, and a dress rehearsal for the final data migration.
Some important elements of the mock migration are as follows:
• It should be executed using the full data set and on the same hardware that will be used to run the production migration. Part of the purpose for this exercise is to get a sense for the timing of the data migration; for large data sets, the migration process may take hours or even days.
• A cross section of the project team should be involved in testing and validating the results of the migration. Users close to the source application and its data will be in the best position to spot problems.
• The mock data migration procedure should be fully scripted beforehand, and a time-stamped log should be kept of every action taken. The time between the mock migration and the actual data migration may be weeks or months; you will not remember every step taken during the mock migration unless it becomes part of the script for the production migration.
There are several common approaches to validating the data migration process:
• Review error logs of data migration tool: This is a good place to start; most tools will log failed transactions that can highlight problems with the data migration process.
• Spot testing This involved identifying some number of records in the source application and checking them, field by field, against CRM to validate that all of the data was translated correctly and that the relationships between records in the source application were faithfully re-created in CRM. This is the only form of testing of the three that can be feasibly distributed across the project team.
When engaging the project team in testing, remind people to be specific when describing issues. Ideally, provide the specific records and fields that were not migrated correctly. General comments like "the data in CRM does not look right" are not helpful.
At the conclusion of testing the mock migration, you will need to make a go/no- go decision regarding the data migration process. If the issues uncovered in testing are minor and can be corrected easily and retested, you are likely ready to proceed. If the test migration uncovered significant issues, you may want to adjust your project plan to allow for a second mock migration after the issues have been addressed.
Planning the Actual Data Migration
The actual production data migration to populate a new CRM application in preparation typically occurs in the evening or over a weekend to minimize the impact to users. Ideally, the user community works in their old application until 5 p.m. on a Friday afternoon, and when they come into work on Monday morning, they begin using the new CRM application and find all of their data has been migrated; they can focus on coming up to speed on the new application, not on data entry.
In this "ideal" data migration model, 5 p.m. on Friday becomes the "cutoff" of the old application. If possible, the entire application is switched to "read-only" mode at this time, and an extract of the data is prepared to be used for the migration. The migration process is executed, using the same procedure as was used for the mock migration. Query and spot testing is performed to ensure that the process has been successful.
As you might imagine, many, if not most, CRM data migrations do not follow this simple pattern, and the particulars of your own migration will drive your own schedule and procedure.
In addition to representing a final test of the data migration process and an opportunity to provide a go/no-go decision for the process, the mock migration provides an all-important sense of the duration of the migration process Ideally, the duration of the migration process will fit into a standard nonworking window such as an evening or weekend. If not, ideally the organization can accept
some downtime to enable a sufficient window to execute the migration. If downtime is not an acceptable option, often data migration can be segmented to eliminate downtime and still allow users to be productive. For example, for the actual data migration, rather than bring over all five years of customer activity data (which might take four days to process and require downtime), one approach would be to migrate only the last year of data and then gradually migrate the older data in each successive nonworking window until all the data has been migrated.
Part of planning your data migration is to develop the detailed script, or series of tasks that will be executed in precise order, to complete the migration successfully. This script is created and refined during the technical development of the data migration process and validated by the mock migration. For the mock migration to have any value, the actual data migration must be executed in the same way using the same script as the mock migration.
Data Migration Summary and Key Lessons
The following are key lessons:
• Data migration is an important part of most CRM projects and can be tremendously valuable but should not be entered into unless justified by sufficient business value. It can be difficult, expensive, and imprecise.
• A common expression that you may have heard, voiced in regard to data migration, is "garbage in, garbage out." Data migration does not magically clean up, standardize, and deduplicate data; if your source applications have quality problems, data migration will simply move those problems into your CRM application.
• Don't outsource testing the data migration to your consulting partner; they do not have the context and understanding of the data and the source application to easily identify problems and sense when something doesn't "look right." Ensure that your team is involved.
For any enterprise application, testing is an important element of both the initial implementation project and all future development projects. Significant application bugs or downtime in enterprise applications like CRM can cripple business operations and have a tremendous negative impact; minor application bugs are an ongoing source of frustration, friction, and job dissatisfaction for users. A new application launch that is marred by significant bugs can put a black mark on the application that can impede adoption and degrade the value you hope to achieve for weeks and months after the issues are resolved.
While you will likely work with a consulting partner on the initial implementation of your CRM application and perhaps on subsequent enhancement projects, testing is one area where the work cannot be completely outsourced. Your consulting team can capably execute unit, system, integration, and performance testing, but they cannot take the lead on user acceptance testing. This is an area where your team's knowledge of your business, data, and processes is vital. A robust user acceptance test with engaged participation from representatives of each CRM stakeholder group is a key ingredient to a successful CRM project.
Types of CRM Application Testing
In this section, we will highlight the different types of testing that may be needed as part of your CRM project, their purposes, and how to integrate them into your project.
This is the initial testing performed by a developer on a newly developed or enhanced application feature, as part of the development process, before flagging the feature as complete. This is a core responsibility of application developers and should be included in all CRM development as a natural part of the process. This testing should explore every possible logical branch of the feature to ensure that it is working as specified in the design. This testing is performed in isolation and is not expected to test the interplay of different features with one another.
Once the development of all the CRM application features is completed and they are deployed in a test environment, system testing ensures that they mesh with one another and still function properly in the presence of the complete feature set. Often individual features can impact one another in ways that individual feature developers do not foresee, so testing the complete feature set together is vital. System testing is typically executed at the end of the build stage of the CRM project life cycle, when all features have been developed and unit tested.
In many organizations, the CRM application is integrated into other business applications such as accounting or provisioning. Integration testing in intended to validate that the application linkage is functioning properly and that data is flowing from one application to another and being translated correctly if needed.
Less important for CRM application deployments with minimal custom development, but critical for those with significant custom development, is performance testing. Large data sets and large numbers of users can have an unexpected and deleterious effect on CRM application performance, resulting in sluggish response times, timeout errors, and frustrated users. A geographically dispersed user community can also trigger performance problems with CRM applications, because network connections between countries can be poor and impact communications between CRM clients and servers. If your project includes significant custom development and one or more of the aggravating factors of data volume, high user counts, or geography, ensure that your project team has included performance testing in their project plan.
The emphasis on custom development for performance testing stems from the fact that the test cases used by the major CRM application vendors likely include both large data sets and large numbers of simultaneous users (assuming you are using an application designed for your size of organization). The standard application, running on appropriate hardware, has likely already been tested and passed in scenarios more rigorous than your own. Custom development, on the other hand, has never been tested, and there are many ways for a developer to author code that fails under high load.
User acceptance testing is a critical validation step in a CRM project life cycle. Prior to user acceptance testing, all CRM components have passed unit and system testing, and all data has been migrated. The test environment is, at this point, essentially identical to the production environment post-launch. User acceptance testing involves exercising the key business scenarios to be supported by the CRM application to validate the following:
• The application, as designed and developed, meets the project goals and is ready for launch.
A unique feature of user acceptance testing is that it is executed by a set of application users themselves: sales managers, perhaps, or customer service representatives. All testing to this point has primarily been conducted by the technical team. User testing is also unique in its all-encompassing nature; application features, migrated data, integrations, and other application areas are all examined as part of the user test.
Thorough test plans explore and validate all logical branches of an application and all-important business scenarios. They should be written with sufficient details such that they can be executed reliably and consistently by multiple individuals.
THEME 9. ANALYSE OF CONSUMER PROFITABILITY
Like post-go-live support, ongoing application management is covered in more detail. That said, identifying a few focal points for you to think through immediately following deployment is important. In this section, we will highlight a few of the early considerations
Driving adoption quickly as part of your CRM implementation will mean the difference between a quick go-live with the potential for positive press and an ugly slog through user issues and complaints. Making sure users see the appropriate value in the application, and are using it fully, will help keep things positive. One common mistake organizations make is allowing users to continue to use or view an old application following the deployment of the new CRM tool. This is one of the most significant errors an implementation team can make because it provides an opportunity for excuses from the user community and will cause nothing but confusion. Of course, if you are going to turn off a previous system, you need to spend the appropriate amount of time ensuring data and needed functionality from the old system is available. In addition, visible and vocal senior executive support during the initial period after launch is important to help users keep the value and vision of CRM in mind and to encourage employees to keep at it until they get comfortable with the new processes and application.
To ensure adoption of the delivered solution, senior executives can choose between the "carrot" and the "stick" approach. While both of these approaches have merit, the decision on direction depends on management style and the existing adoption of other applications within an organization. Based on our experience, few managers have the stomach to make the "stick" work in the absence of "carrots," so keep that in mind as the go-live process progresses. "Carrots" may include recognition of users who are embracing the application or small bonuses for helping evangelize the application. An example of a "stick" (for a sales team) might be a policy whereby commission is not paid on won deals unless they were recorded and tracked in the CRM application.
Tying KPIs and Compensation to CRM Usage
One of the more prevalent ways of using the stick to drive application usage is tying an individual's objectives or compensation to CRM usage. Whether the CRM usage you are looking for is as simple as tracking e-mail correspondence or activity or as complex as providing detailed sales stage and status information on sales opportunities, you should be able to successfully find unquestionable metrics to use to govern compensation. Consider defining an algorithm that factors in usage, number of records updates, and number of activities tracked and producing a peruser score. You can also make sure that users get paid commission only on opportunities that were in the system for a specific period of time. This will prevent someone from entering information only when they get a signed contract
Like most of the topics in this section, change management is discussed more heavily in Chapter 7. Immediately following go-live, it is important to leverage the tools we provide in Chapter 7 to track any immediate feedback about the application. You may want to schedule steering committee discussions regularly following go-live, potentially even daily for 10 or 15 minutes to discuss any high-priority issues that come up. The steering committee should be prepared to review issues and update the team quickly with progress and mitigation steps (if appropriate). Additionally, consistent communication about the status of the application, benefits provided by the new tool, and highlights of key features will enable you to drive a more positive outlook and be more responsive to any concerns raised by the team.
People Management: New Job Functions
CRM implementation in and of themselves will not change how your people function; it may require them to operate differently within the purview of their current job. Perhaps people used to hand paper orders to someone in accounting for processing and will now enter them themselves in CRM. Perhaps users formerly had to spend a significant amount of time reporting pipeline status, but that process is now automated. Whether they have additional time to spend on high-value pieces of their job or have slightly different workflows associated with day-to-day tasks, you should be prepared to support them as much as needed during the transition period.
Pulling It All Together: Sample CRM Implementation Project Plan
In this chapter, we've organized content by topic, such as data migration, reporting, and so on, rather than by how you will organize the work of your project chronologically. In Figure 6-19, we've laid out a high-level project plan to help illuminate this second perspective: how the project work is actually laid over a calendar and completed.
Here are some important notes about the diagram:
• The iterative project process that we have discussed is depicted. Design work continues well into the iterative build stage as adjustments are made based on the project team's interactions with prototypes of the CRM application.
• Since they are ultimately dependent on the design of the application, the report, integration, and data migration designs will likely change somewhat after the initial design phase in the iterative approach to reflect changes made to the application during the iterations. All other designs cannot be "chipped in stone" until the application design is finalized.
Items are not listed within each stage in a specific order to reflect the sequence of their completion.
Common Project Issues and How to Avoid Them
Now that we have provided you with an overview of the various processes and tools that can be used to help you implement your CRM application, we wanted to outline a few of the classic project issues that arise with CRM implementations. We will
provide a few of the symptoms or causes of these issues and a bit of information on steps you can take to avoid them.
At various points in this book, we talk about using a phased or big-bang approach to CRM. Over-scoping is another way of articulating the same challenge. Allowing too much scope, or scope that collectively requires too much change, into your CRM implementation will provide significant challenges to you as you roll out the first version of your CRM application. It isn't just the volume of scope that defines whether a solution is over-scoped but the complexity of the scope as well. If you include numerous integrations, multiple system replacements, or other complex items, your user community could become overwhelmed by the change.
Focusing on small, manageable deployments is the easiest way to mitigate the risk of over-scoping. If you can, break the first phase of the implementation into a small, meaningful set of scope that provides distinct value to the end user community. Once you've had a successful phase, finding more time, budget, and success should be a straightforward process. If you do need to do a large implementation as part of the first phase, critically review the scope items to ensure that no one user group is over burdened by the change. You can also devote extra time to training and user support to help alleviate any of the extra risk added by a larger scope volume Overly Complicated Design
Whether you are simply designing the account and contact entities or are focused on a broad set of custom entities and attributes in your CRM application, trying to make them all things to all people can quickly cause conflict when it comes to the form layout and usability. This conflict exists whether looking at CRM forms or the complexity of integrations and custom items in your CRM program. Building too much up front or not carefully managing the expectations of users can cause the design and, ultimately, the implementation of your CRM system to become too complex and will cause issues with user adoption.
We often hear our customers and other consultants talk about using out-of-the- box functionality whenever it is available. This is absolutely one place to start when looking to avoid an overly complicated design of your CRM application. In addition to focusing on native CRM features, having someone involved in the project who can objectively look at the various requests for customization or automation and provide guidance on what to build initially will help ensure your design both meets users' needs and remains as uncomplicated as possible.
A common mistake most organizations make is allowing the features available in various CRM applications to drive the overall implementation. Whether they change an existing, working process to fit within the new CRM tool or implement a feature just because it is available in the tool, this immediately puts the adoption of the tool at risk. Any time users are required to change a process for the sake of technology, they are more likely to rebel against the application and look for workarounds to the new application. Additionally, this approach often leads to over-scoping, which will cause many of the same issues.
With the technology available today, virtually anything can be customized or built into your CRM application. Focus on using the tools to make the application fit your organization's desired processes. We recognize that endlessly building things into your CRM tool is both costly and time-consuming, so it may be important to prioritize items that do the most to facilitate processes, but eventually, with the right focus and continued dedication, you will eventually implement all the necessary functionality to meet all the process requirements.
At virtually all points throughout your project, having the appropriate level of executive support is crucial to finding the right vendor (if appropriate), helping set the implementation team's priorities, and guiding the overall project. Following the initial deployment, executive support is critical to helping drive user adoption for the solution and ensuring any issues that arise are both communicated appropriately and dealt with in the appropriate way. If at any point the support from the executive team, or even just the level of communication, begins to wane, this will represent a risk to your project that should be dealt with quickly.
Managing any issues that arise around the level or amount of executive support is generally pretty straightforward. Fortunately, most executives respond when presented with a risk that will cost them either money or trust, so simply raising the issue will often raise the level of participation. If that alone does not work, look for opportunities to help them with things like communication by drafting project emails. Finally, ensuring that they have all the necessary information at hand when talking about the value of CRM or are addressing any issues will make them much more likely to participate heavily in the process.
Whether the conflict is focused on the CRM implementation or a conflict pitting CRM priorities against something unrelated, being able to manage the varying priorities of your stakeholders on the project will be key to getting the appropriate level of
participation from them. If individuals on the project team have differing project priorities, dealing with them from the very beginning of the project can be a big win.
Tools such as the project charter, project status discussion, and even design documents can be used to bring the team together and raise any important issues. If the conflict exists between CRM priorities and those associated with another organizational initiative, your executive sponsor and project steering committee are going to be the best mechanisms for you to resolve any problems. The larger your organization is, the more likely these types of conflicts are to occur. If necessary, plan to build some additional time into your project plan to account for small shifts in priorities throughout the project.
We discussed application adoption earlier in this chapter. With that information in mind, all of the items outlined in this section of the chapter can contribute to a lack of application adoption. Having priorities that spread users too thin, over-scoping, a perception of lukewarm executive support, and other items should all be avoided where possible to allow users to adjust to the new application. Issues with application adoption could derail both your initial implementation and your ability to get support (and funding).
Addressing concerns quickly is important. Providing additional training, support time, and resources to your team throughout the process will enable the implementation to go well and should position your team well for any future phases.
THEME 10. BUILDING A CRM ROADMAP
Establishing a well-considered, thoughtful plan for implementing a CRM program can help you strike the best balance between your organization's priorities and initiatives and the needs and preparedness of different departments. A haphazard, unplanned implementation can result in disjointed business processes, dissatisfied employees, and excessive implementation costs. When it comes to planning your CRM program, "An ounce of prevention is worth a pound of cure."
In this chapter, we'll review the process of outlining a one- to three-year plan for your CRM program, which we'll refer to as your roadmap. All organizations should develop and maintain a CRM roadmap—whether they are just beginning to think about CRM or whether they have a successful, mature program in place. The roadmap is a constantly evolving document, reflecting your changing business situation and priorities and maintaining that one- to three-year look into the future. In the next section, we will consider the rationale behind a phased approach to CRM. Then we will explore the development of your initial roadmap.
Why a Phased Approach to Your CRM Program?
When you have developed your initial vision for your overall CRM program, it may be tempting to try to realize the entire scope with a single project. This appears to be the most direct and shortest path to achieving the vision. We strongly discourage this type of "big-bang" approach, where your organization attempts to move from "no CRM" to "full CRM vision" in a single project. In this section, we hope to convince you that a phased approach, whereby several smaller projects are chained together to progress toward the complete vision and grow the footprint of CRM, is a much more sensible approach and will increase the success of your program. Building internal momentum for one big push may seem easier, and rolling out the program to all employees at once seems simpler than coordinating multiple phases, but do not be fooled.
The following sections are a few of the problems with the "big bang" that are addressed via a phased approach.
The longer the duration of a business process and technology application project like CRM, the greater the likelihood of failure, because of a number of factors. Turnover on the project team saps the team of its institutional memory—decisions are rehashed and redebated as new team members join, further slowing project progress. The larger the project scope, the more stakeholders must be involved, demanding a voice in the decision making and resulting in a slower, committee-driven project. Fatigue saps the energy from the project sponsor and other executives, who grow weary of selling the benefits of a project to increasingly skeptical employees who grow to doubt that the program will ever launch. The longer the project duration, the more time elapses between the design of the CRM processes and application and their rollout. At the pace of business change today, the longer this time period, the further out of alignment the program will be with the reality on the ground and the needs of the employees when it actually launches.
In a phased approach, each project is smaller in scope and shorter in duration, with fewer objectives and stakeholders. Each project builds on the prior and expands the reach of CRM within your organization, addressing a new department or business process. We will introduce guidelines for how to break your program into phases to build your roadmap later in this chapter.
There Are No Opportunities to Incorporate Feedback
With a phased approach, there is the opportunity to do a post-project review after each project phase and incorporate lessons learned and successful practices into the next phase so that your project execution is theoretically improving with each phase as you refine your project methodology to best suit your organization. With the big bang, there are fewer opportunities for this type of learning, because each stage in the project is fundamentally executed a single time.
In this section, we'll focus on the process to build your initial roadmap to launch your CRM program. If you have already established a CRM program and deployed a CRM application, we'll cover the special case of developing a roadmap after you've already implemented a CRM application in the "Developing a Roadmap Midstream" section.
The heart of roadmap planning is assessing your current situation and your strategic goals; a study of these should suggest a set of initiatives that then need to be ordered and scheduled appropriately to maximize efficiency and minimize risk.
A useful first step in building your roadmap is to document your current business processes as they function today. You may find inconsistencies in process across employees or departments that perform similar functions—this is common. Many of your planned CRM initiatives may require process changes, and having the current state documented will help map out and create understanding of the implications of changes. This work may also reveal inefficiencies, processes that create a poor customer experience, or opportunities to share best practices from one user or department to another. In general, you should strive for process consistency whenever it is practical—there are a host of benefits from all employees and departments tackling the same task in the same way, and to the extent this consistency is felt by the customer, it will improve his or her experience as well.
Current Customer Information Applications
Create a catalog of the different applications used to manage customer information or customer-related processes. This catalog should describe who uses each application, for what purpose, and how the application is used in the context of your organization's processes. Interview users to understand their perception of each application's strengths and limitations. This process is likely to be eye-opening. Most organizations develop their processes and tools in grassroots, bottom-up fashion, in reaction to changing circumstances, and with little strategic perspective. You will likely find multiple applications that hold the same information, processes that require redundant entry into multiple applications, and an abundance of small, Microsoft Excel or Access solutions to solve specific problems. This tapestry of applications can hinder user productivity and prevent effective collaboration between your employees. We are not suggesting that there should be a single, monolithic application within an organization but simply that your array of applications should be the result of a rational plan—selected to maximize employee productivity and effectiveness and provide a superior customer experience. In most organizations, this is not the case.
Part of your assessment process is to "find the pain" in your customer-facing teams. At the risk of stating the obvious, these pain points may signal a people/process/technology breakdown that needs to be addressed. So, follow the complaints. Who is arguing for change? What team or function consistently fails to meet expectations? Is there more employee turnover? Analyze the situation—what is causing the underlying problem? Who is impacted,
and what is the business value of addressing the pain? Is addressing this pain in line with the organization's strategic goals?
Your organization's strategic goals and strategic plan play an important role in shaping your CRM roadmap. They may be a direct source of initiatives for the roadmap. For example, if your plan includes entering a new market or pursuing a new customer segment, this will likely require CRM people, process, and technology changes to support the effort. In addition to directly contributing to your set of CRM initiatives, your strategic goals also serve as an important lens on evaluating initiatives for inclusion in the CRM roadmap. For example, you might deprioritize initiatives to support a product line or sales channel that is becoming less relevant or being phased out because of a new strategic direction.
Most CRM programs involve a technology component, so it is helpful as part of your assessment to understand your technology landscape and what the IT roadmap looks like within your organization so that you can align your own roadmap accordingly. For example, if your IT organization is planning a complete overhaul of your corporate web platform in Q3, you probably should not invest in integrating your CRM application and your web site in Q2. Major application deployments, IT head count changes, and IT skill set changes can all impact your roadmap and should be understood and factored into your planning.
Early detection of "red flags"—issues that may endanger the success of your program—gives you the most time to formulate a plan to neutralize or avoid them. As you conduct your assessment, keep a running list of red flags you identify, and consider how to address them. Common red flags that we have seen in pursuing CRM programs successfully include the following:
• Weak executive sponsorship or buy-in: For example, a sales leader who does not understand or believe in the value of CRM will make a successful sales-focused program very difficult. Significant turnover at the executive level can also make development of the CRM program difficult, because each new leader wants to impose his or her own priorities on the program, and CRM does not get a chance to build momentum in any one direction.
• Limited IT resources, combined with an unwillingness to invest in consulting assistance To continually improve and adjust to changing business circumstances, your CRM application will require regular investment. Organizations without IT resources (for example, developers, testers) need to be ready to contract for these skills to ensure the vitality of their program. An area where we often see insufficient investment is in reporting, where organizations seem to chronically underestimate the effort involved. This is a red flag because effective reporting and analytics are a critical source of CRM value for management.
• Weak business analysis skills within affected departments: CRM programs need a detailed-oriented, dedicated management team to make them successful. These teams need individuals who understand the organization and its processes and have enough application savvy to help translate the business needs into application capabilities.
Split Your CRM Vision into Projects
Once you have completed your assessment, you should have a number of departments and business processes identified that could be improved, with respect to either their people (for example, how they are staffed, what employee roles and responsibilities are, and so on), their processes, or their technology tools. The next goal is to assemble these into discrete projects and sequence those projects against a calendar. This is the heart of the roadmap development. We described earlier in this chapter the rationale behind a phased implementation approach and will not revisit that here; in this section we want to provide some perspectives that you should consider to understand how to group your various needs into individual projects and how to sequence them in the most advantageous way. There are no hard-and-fast rules, but there are a set of considerations that will be helpful:
• Business impact You will learn from your assessment what areas of your organization have the greatest need and where there is the greatest potential for increased productivity and effectiveness. Barring all other factors, it makes sense to pursue these areas first.
• By department. Centering a project around a single department can have a number of advantages; it minimizes the number of stakeholders involved, making project management easier. The more of their work an individual employee can complete with just a single tool (the CRM application), the more likely they are to see the value in the tool and adopt it.
By business process: It can be disjointed and unworkable to change only part of a business process. Imagine, for example, a software organization with a customer service organization and a software quality team. Issues are often escalated from customer service to software quality, when the issue is related to a software defect. Imagine transitioning the customer service issue management process to your new CRM application but leaving the old Access database in place for the software quality team. Issues would be smoothly escalated through customer service, with CRM workflow handling reassignments and notifications. Then, when escalation is needed to software quality, the process just "falls off a cliff"— customer service reps end up cutting and pasting information from the CRM service case into an e-mail to someone on the software quality team. If and when that person gets to it, they must cut and paste the details from the e-mail into the Access system to be worked by their team. There is no automation or workflow from this point. Customer service has no visibility from their CRM application into the status of the issue once it is in software quality, so they cannot give customers any information when they call but rather must take a message and follow up. This is not ideal for your employees and not ideal for your customers and is the result of spreading the same business process across multiple CRM projects.
By geography. Organizations with geographically dispersed teams that each work with their own local customers are potential candidates for separate CRM projects. Remote and/or smaller teams that tend to handle multiple processes in a location are often receptive and eager to be part of a pilot program that streamlines their process.
By duration/effort: Large CRM projects can bog down and in some cases collapse under their own weight—caught in endless cycles of analysis or never-ending development phases. All else being equal, there is value in having the first one or two projects in your roadmap be fairly small in scope and low in risk. If you can get some set of employees up and running with the program and start seeing some benefits for the organization, it will help build momentum behind CRM in your organization and will dispel fears that CRM is "not real" or "will never happen." You'll also begin to get real feedback from employees that you can feed into future projects to improve them.
Another factor to consider in designing projects is outcomes—how will success or failure be judged for each project? What are the outcomes that each department expects from the projects that involve it? Ideally each project would include clear, agreed-upon success factors so that there is an objective way to gauge a project's outcome.
Once your CRM assessment is complete and you have developed a preliminary roadmap of projects based on the factors outlined in the prior section, your roadmap planning work is not yet complete. The effort required to launch a CRM program is significant, and it is therefore important to evaluate your draft roadmap from the "people perspective." Plan an individual conversation with the leaders of each department impacted by your roadmap to explore the following:
• Bandwidth: Does the department have a clear understanding of the "asks" that will be made of them by the CRM team for the CRM projects that involve their department? Can the department free the right people for the necessary time to make the project successful? Your CRM team cannot deliver successful CRM projects on their own—each project should be viewed as a partnership between the CRM team and the departments involved. You need to confirm that each department is ready and able to pull their own weight and participate fully.
• Buy-in: Different executives within your organization will have different levels of "belief" in the CRM program and its benefits. You may find that some are skeptical or even hostile, based on poor experiences in their past or on the nature of their team. They may view the CRM program as a "distraction." As we have discussed previously, strong, evangelical executive support is a key success factor for CRM projects, so if you encounter these types of attitudes, consider it a significant red flag. You probably want to be thoughtful about how to schedule and structure projects with departments led by "CRM skeptics." For example, avoid addressing these departments with your initial project; it's better to get some early wins with other groups and build momentum behind CRM before tackling these departments. If you must include them early in your roadmap, attempt to broaden the project to include departments led by strong "CRM believer" executives of similar rank to help ensure strong executive leadership.
Pilots and the "Proof-of-Concept" Project
Pilots and "proof-of-concept" projects can be considered just another type of CRM project that should be fit into your roadmap as needed. These special projects serve a specific purpose—to validate a specific element (that is, process or technology tool) in a small-scale, low-risk way prior to a larger-scale project. The two terms are often used interchangeably, but in our lexicon they have distinct meanings.
A pilot refers to a complete project that delivers the changes planned for the entire organization to a small segment to get a preview of what the results will be for the entire organization. The project is complete in that the affected segment changes the way they conduct actual business; it is not a simulation or test. For example, before rolling out a new process and technology tool for collaborative customer proposal generation to 2,000 U.S.-based field sales personnel, an organization might choose instead to pilot it by rolling it out to the 100 salespeople in the Los Angeles office for a period of six months. This approach minimizes the organization's risk—if the changes have a negative impact or otherwise fail to deliver on their goals, only 5 percent of the sales organization is affected. The downside is of course the delay; if it proves wildly successful, the organization has lost six months of benefit to the rest of the sales team via the pilot approach. Critical to a successful pilot is an up-front consideration of outcomes—what outcome will trigger an organization-wide rollout, and what will trigger rework or abandonment of the effort? How will these outcomes be measured, and by whom?
A proof-of-concept is a more limited project, generally intended to prove a technology tool before full development. In a proof-of-concept, no change is made to how the organization conducts its actual business; it is simply a research project to explore whether something can be done in some small way before attempting to do it in a large way. For example, imagine that a paper products company wants to outfit its field sales team with a mobile device that will allow them to initiate a variety of transactions in the company's ERP application (for example, placing a new order, checking an order status, getting approval for a discount) from a customer's location. The mobile device vendor assures the company that this can be done, but they have no experience integrating their device to the company's ERP application, and they have a limited understanding of the company's network security that would need to be navigated to allow remote transactions. Before embarking on a full design and development project to roll the device out to the global sales force, the company elects to conduct a proof-of-concept. The goal is to build a light sample application that can connect to the company's ERP application from a remote location and retrieve an order status. This is a dramatically smaller project with limited design and development work (the application does not need to look good or be easy to use—no salespeople will ever see it, and it needs to support only a single type of transaction). But if successful, it proves that the vendor can navigate the company's network security and interact with the ERP application. Proving these points eliminates much of the risk associated with the larger project. As with the pilot example, the trade-off for this risk mitigation is time and dollars—the full project is on hold while the proof- of-concept is delivered, and including a proof-of-concept project increases the overall cost of the initiative. As with the pilot, thoughtful consideration of what the goals of the poof-of-concept are, and what outcome constitutes "proof," should precede the project.
Both pilots and proof-of-concept projects can be useful to control risk in your CRM program, but they have a schedule and cost impact that must be considered.
In this example, we'll consider the case of IdeaShare, a fictional maker of payment- processing software. IdeaShare has been on a slow but steady growth path over the past few years but has recently undergone a leadership change. The new leadership wants to pursue growth more aggressively with the goal of either a public offering or an acquisition. To drive this growth, they have developed a new strategic plan that includes goals to increase IdeaShare's business in the education and government markets where they are currently not active, invest in customer service to eliminate a reputation for poor service that is suspected to be interfering with sales, develop a partner sales channel, and accelerate the development of IdeaShare's next- generation product. Fiona Smith, the IdeaShare COO, has been tasked by the CEO and owners with exploring a CRM program at IdeaShare. Please note that the goal of this example is to help illuminate the concepts from this chapter; we've prioritized this goal over attempts to make the example too realistic.
THEME 12. AUTOMATIZATION OF BUSINESS PROCESESS IN CRM
Many customer business processes cross application boundaries. For example, the process of onboarding a new customer begins in the CRM application with a won sales opportunity or order but soon crosses into accounting, where a new customer record must be set up, order fulfillment initiated, and perhaps an invoice prepared. For services organizations, the sold project and customer may need to get created in an enterprise project management application.
Without application integration, the points where these processes cross an application boundary can be associated with delays, redundant, error-prone data entry, and incomplete information. Information from one application must be manually rekeyed into another. An action or event in one department must be communicated to others, via e-mail, phone, or a meeting.
Application integration allows these interactions between applications to occur programmatically, triggered by application events and occurring without user intervention. When a company's status changes from "prospect" to "customer" in the CRM application, the customer information is automatically passed to accounting, and a corresponding customer record is created. Perhaps the accounting team receives an automated e-mail to alert them of this event. If a services-type sales opportunity is won, that event in CRM can trigger the creation of a customer and project record in the enterprise project management application so that the delivery team can get to work planning for service delivery.
In another form of integration to automate business process, an element of another application's user interface is embedded within the CRM application so that
at a certain point in a process, a CRM user can quickly manually enter data or initiate a transaction in the other application from within CRM. This is useful if some user oversight or judgment must be applied in how the information is entered into the other application.
Two types of integration are commonly seen in CRM projects: data-level integration and user interface integration. Scenarios exist where one is more appropriate than the other; your integration needs and the nature of your applications will guide you in selecting an approach.
Data-level integration involves physically copying data from one application to the other. This type of integration is typically more involved to design, develop, and test. However, it has the advantage of making the data from one application fully available to all the functionality of the other. For example, if via integration we copy invoices from the accounting system into CRM, they are available for use in CRM reports, available to trigger notifications and other workflow rules in CRM, can be secured using the CRM security model, are able to be fed into e-mail messages generated into CRM, and so on.
One area to be defined for data-level integration is the direction that data will "flow"; for example, we have given examples where a customer record moved via the integration from the CRM application to the accounting application. What happens if someone updates the customer record, say by changing a phone number, in the accounting application? Should that change flow the other way and update the CRM record for that customer? Decisions must be made as to how data should flow through the integrations and which systems "master" which data (in other words, their version of the data is always considered "true" and overrides all other systems).
This form of integration involves embedding an element of one application's interface, or perhaps a report of data from the application, into another application. The data never physically moves from one application to the other; a view of it is simply presented to the user in the other application. This is useful when the key requirement is simply to show data to the user or to make it easier for them to initiate a transaction. This type of integration is simpler to design and develop than a data- level integration. To revisit our invoice integration example from the prior section, rather than implement a data-level integration to copy invoice data to the CRM application, we could develop a user interface integration, where a report of customer invoices from the accounting system is displayed in a tab on the CRM customer record. CRM users can view this information as if it were part of the CRM application. However, they could not query it via CRM search tools, and it could not participate in CRM workflow automation and other CRM features.
For user interface integrations, typically the amount of custom programming required is small, and no integration tool is required. Most CRM applications include some capability for embedding external content in the user interface; the trend toward browser-based clients makes this even easier.
For data-level integrations, pure custom development is still an option, but the programming effort is much greater. Most organizations opt for implementing an off- the-shelf integration tool and then build their data integrations using it. The tool provides the low-level functionality (for example, error handling), connectors to common business applications, and a host of data transformation features to facilitate mapping and transforming data to move it from one application to another. The programming effort saved using one of these tools easily justifies its costs, and the result is easier to use and administer. Tool selection will be driven primarily by the type of integration needed, the applications involved, and your team's technology expertise and infrastructure.
Managing Data-Level Integration in CRM Projects
Integration efforts follow the familiar design-build-test-deploy of any CRM project, but in this section we will discuss some of the tasks specific to data-level integration work.
Identify Integration Scenarios and Applications Involved
The first step is to map out the desired integration scenarios, the direction of data flow, and the applications involved. This information can be concisely described with a table.
Once you have outlined the integration scenarios, you must develop a data map for each. This exercise is very similar to the data mapping required for a data migration effort; you can consider integration as a kind of ongoing data migration. For each scenario, you must define how fields from one application map to the other, and you must note any transformations required to the data as it passes from one system to another.
There are a few unique challenges associated with integration development that merit discussion; all of the tips for managing custom development work apply here.
One specific requirement for integration development is that the development team has a test instance of each application to be involved in the integration. This can be significant to set up and should be accounted for in your budgeting and scheduling for the integration work.
As with the other components of a CRM project, there should be a documented test plan for integration. It's also especially important with integration to involve business stakeholders and subject-matter experts. It often takes people who are experts in the applications being integrated to CRM to spot problems with integrations.
Managing User Interface Integration in CRM Projects
User interface integration work is closer to standard custom development work than to data-level integration. There are a few unique challenges associated with designing and developing user interface integrations that merit discussion; all of the tips for managing custom development work apply here. One challenge that must be addressed for both user-level and data-level integrations is how to link data from one system to the other; this topic is described in the next section.
A core challenge with developing integrations is how to link data from one application to another. For example, given an account record in the CRM application for the Jones Corporation, how can the integration program locate the record in the accounting system that represents the same organization? There needs to be some kind of unique link that tells the integration that record in one application represents the same real-world entity as record in a second application. As you have probably guessed, the name is not enough; what if the accounting system record is named Jones Corp?
One common solution to this challenge is to store the unique identifier from one application on the corresponding record in another system. The unique identifier, present in nearly all database applications, does just what you would think; it uniquely identifies a single record, just like a Social Security number uniquely identifies an American citizen.
THEME 13. DEVELOPMENT OF CONSUMERS
People Management: New Job Functions
CRM implementation in and of themselves will not change how your people function; it may require them to operate differently within the purview of their current job. Perhaps people used to hand paper orders to someone in accounting for processing and will now enter them themselves in CRM. Perhaps users formerly had to spend a significant amount of time reporting pipeline status, but that process is now automated. Whether they have additional time to spend on high-value pieces of their job or have slightly different workflows associated with day-to-day tasks, you should be prepared to support them as much as needed during the transition period.
Pulling It All Together: Sample CRM Implementation Project Plan
In this chapter, we've organized content by topic, such as data migration, reporting, and so on, rather than by how you will organize the work of your project chronologically. In Figure 6-19, we've laid out a high-level project plan to help illuminate this second perspective: how the project work is actually laid over a calendar and completed.
Here are some important notes about the diagram:
• The iterative project process that we have discussed is depicted. Design work continues well into the iterative build stage as adjustments are made based on the project team's interactions with prototypes of the CRM application.
• Since they are ultimately dependent on the design of the application, the report, integration, and data migration designs will likely change somewhat after the initial design phase in the iterative approach to reflect changes made to the application during the iterations. All other designs cannot be "chipped in stone" until the application design is finalized.
Items are not listed within each stage in a specific order to reflect the sequence of their completion.
Common Project Issues and How to Avoid Them
Now that we have provided you with an overview of the various processes and tools that can be used to help you implement your CRM application, we wanted to outline a few of the classic project issues that arise with CRM implementations. We will provide a few of the symptoms or causes of these issues and a bit of information on steps you can take to avoid them.
Over-scoping
At various points in this book, we talk about using a phased or big-bang approach to CRM. Over-scoping is another way of articulating the same challenge. Allowing too much scope, or scope that collectively requires too much change, into your CRM implementation will provide significant challenges to you as you roll out the first version of your CRM application. It isn't just the volume of scope that defines whether a solution is over-scoped but the complexity of the scope as well. If you include numerous integrations, multiple system replacements, or other complex items, your user community could become overwhelmed by the change.
Focusing on small, manageable deployments is the easiest way to mitigate the risk of over-scoping. If you can, break the first phase of the implementation into a small, meaningful set of scope that provides distinct value to the end user community. Once you've had a successful phase, finding more time, budget, and success should be a straightforward process. If you do need to do a large implementation as part of the first phase, critically review the scope items to ensure that no one user group is over burdened by the change. You can also devote extra time to training and user support to help alleviate any of the extra risk added by a larger scope volume Overly Complicated Design
Whether you are simply designing the account and contact entities or are focused on a broad set of custom entities and attributes in your CRM application, trying to make them all things to all people can quickly cause conflict when it comes to the form layout and usability. This conflict exists whether looking at CRM forms or the complexity of integrations and custom items in your CRM program. Building too much up front or not carefully managing the expectations of users can cause the design and, ultimately, the implementation of your CRM system to become too complex and will cause issues with user adoption.
We often hear our customers and other consultants talk about using out-of-the- box functionality whenever it is available. This is absolutely one place to start when looking to avoid an overly complicated design of your CRM application. In addition to focusing on native CRM features, having someone involved in the project who can objectively look at the various requests for customization or automation and provide guidance on what to build initially will help ensure your design both meets users' needs and remains as uncomplicated as possible.
Software-Driven Projects
A common mistake most organizations make is allowing the features available in various CRM applications to drive the overall implementation. Whether they change an existing, working process to fit within the new CRM tool or implement a feature just because it is available in the tool, this immediately puts the adoption of the tool at risk. Any time users are required to change a process for the sake of technology, they are more likely to rebel against the application and look for workarounds to the new application. Additionally, this approach often leads to over-scoping, which will cause many of the same issues.
With the technology available today, virtually anything can be customized or built into your CRM application. Focus on using the tools to make the application fit your organization's desired processes. We recognize that endlessly building things into your CRM tool is both costly and time-consuming, so it may be important to prioritize items that do the most to facilitate processes, but eventually, with the right focus and continued dedication, you will eventually implement all the necessary functionality to meet all the process requirements.
Lack of Executive Support
At virtually all points throughout your project, having the appropriate level of executive support is crucial to finding the right vendor (if appropriate), helping set the implementation team's priorities, and guiding the overall project. Following the initial deployment, executive support is critical to helping drive user adoption for the solution and ensuring any issues that arise are both communicated appropriately and dealt with in the appropriate way. If at any point the support from the executive team, or even just the level of communication, begins to wane, this will represent a risk to your project that should be dealt with quickly.
Managing any issues that arise around the level or amount of executive support is generally pretty straightforward. Fortunately, most executives respond when presented with a risk that will cost them either money or trust, so simply raising the issue will often raise the level of participation. If that alone does not work, look for opportunities to help them with things like communication by drafting project emails. Finally, ensuring that they have all the necessary information at hand when talking about the value of CRM or are addressing any issues will make them much more likely to participate heavily in the process.
Managing Differing Priorities
Whether the conflict is focused on the CRM implementation or a conflict pitting CRM priorities against something unrelated, being able to manage the varying priorities of your stakeholders on the project will be key to getting the appropriate level of
participation from them. If individuals on the project team have differing project priorities, dealing with them from the very beginning of the project can be a big win.
Tools such as the project charter, project status discussion, and even design documents can be used to bring the team together and raise any important issues. If the conflict exists between CRM priorities and those associated with another organizational initiative, your executive sponsor and project steering committee are going to be the best mechanisms for you to resolve any problems. The larger your organization is, the more likely these types of conflicts are to occur. If necessary, plan to build some additional time into your project plan to account for small shifts in priorities throughout the project.
Application Adoption
We discussed application adoption earlier in this chapter. With that information in mind, all of the items outlined in this section of the chapter can contribute to a lack of application adoption. Having priorities that spread users too thin, over-scoping, a perception of lukewarm executive support, and other items should all be avoided where possible to allow users to adjust to the new application. Issues with application adoption could derail both your initial implementation and your ability to get support (and funding).
Addressing concerns quickly is important. Providing additional training, support time, and resources to your team throughout the process will enable the implementation to go well and should position your team well for any future phases.
Throughout this chapter, we have provided an overview of the different elements of your initial CRM project. Many of these topics could have a book dedicated to them alone, so we have provided what we feel is enough information to get you started and have some simple yet effective templates to work with. Based on our deep CRM consulting experience, we have also worked to identify some of the pitfalls associated with typical CRM implementations. When combined, it is our hope that this information gives you enough to ultimately be successful with the first step in your CRM program.
• Spending time up front in the project documenting the processes to be impacted by CRM will help align the team and result in a smoother project with fewer surprises.
• Custom development introduces risk to your project but can significantly increase the value of the application and its fit to your organization's processes.
• Data migration is a difficult and expensive task; limit it wherever feasible, and be realistic about its value.
• Integrating CRM with other business applications can set up employees to provide a better customer experience and make them more productive.
Reporting is a key project element; consider the desired reporting outcomes at the beginning of the project and periodically throughout the design process to ensure that they will be delivered by the completed application.
THEME 14. SOFTWARE OF CRM
Through this point in the book, we have discussed some of the items that will dramatically impact the success of your CRM program. Keeping the components of a successful CRM program in mind as you and your team work through the initial stages of a CRM implementation will allow you to focus on the task at hand.
In this chapter, we will be concentrating on planning the first-phase implementation of your CRM software. We will walk you through the typical phases of an implementation, focus on dividing the available work, and talk through some of the detailed items that can make or break your implementation. More specifically, we are going to focus on concepts that should be evaluated or completed before the project begins. Although many of the concepts are not related to each other, it will be vital to evaluate each high-level item. They are all important when trying to effectively plan your initiative.
Of primary importance to the Waterfall methodology is sequence. Generally, one step must be 100 percent complete prior to taking on the next. Additionally, this methodology is very heavily focused on documentation. The rigid structure of the Waterfall methodology often causes problems for implementation teams. A CRM project rarely moves in a straight line, so an ability to be creative and adapt project schedules to meet the team's needs is important. The heavy focus on documentation also puts a significant burden on the project team. Stakeholders are often stretched thin with their "day jobs" to begin with, so adding the weight of detailed documentation frequently causes all their work to suffer.
Another common methodology is Scrum. The primary premise of this methodology is short, fixed-length design and development cycles. Scrum cycles typically range from two to four weeks and include very fixed scope. These cycles are often referred to as sprints. Each sprint begins with a discussion where the collected list of desired features is reviewed by the project team. The team then identifies the features that can successfully be developed within the two- to four-week sprint period, and then the work begins.
One key premise to the Scrum methodology is that once a sprint has been identified, it cannot be changed. That said, another key principle is flexibility. Because sprints are short in duration, the user community can more easily change their mind or approach to a requirement and can implement that change in a subsequent sprint. Items identified as features for the next sprint are called the sprint backlog.
Even though they're short, many of the activities identified in the SDLC are used, albeit in an abbreviated fashion. A brief design and development phase is followed by a demonstration of the new functionality. This demonstration replaces the more detailed training activity that occurs in longer projects. By nature, the project teams using the Scrum methodology meet regularly and briefly cover any items discussed in the plan/analyze phases through the life of a sprint.
Iterative Development Methodology
Both of the methodologies outlined thus far have some limitations when associated with CRM implementations. Based on our experience, one of the biggest places where implementations can fail is a lack of user buy-in. One of the challenges with the Waterfall methodology is that the need to complete one stage before beginning the next requires the project team to develop a very detailed design document. This document is developed with input from the end users and reviewed prior to the beginning of development. Ultimately, the next time the user community will see the application is during user acceptance testing, so this approach opens the door for users to be surprised or disappointed with some of the assumptions or trade-offs made.
Many CRM implementations include enough functionality that short design sessions and quick development cycles associated with the Scrum approach make meeting users' expectations for an initial implementation difficult. Even the smallest of CRM implementations may take a number of weeks, with larger implementations taking 6 to 12 months or more. Additionally, one key premise of Scrum projects is a brief demonstration of new functionality to users instead of a full user training cycle. With most initial implementations, spending a significant amount of time educating users about the application, including where it can help them be more efficient in their jobs, is important.
Because of these and other limitations associated with many methodologies, we often employ a derivative of the iterative development methodology on our projects. This methodology is often referred to as the iterative and incremental development methodology. With this methodology, the idea is to loop your application through a repetitive (iterative) design process over a shorter period of time (incremental). Visually, this methodology looks very similar to the Waterfall methodology with two key differences:
There is an overlap between stages when using the iterative development methodology. Much of the work to be completed in a particular stage can be started prior to the end of the previous stage.
During the design phase, the iterative approach provides the implementation team with a mechanism to gather requirements, build or configure pieces of the application, and then repeat the process.
Calculating and measuring ROI for a CRM project can be a challenging task. Rarely does an organization have the ability to successfully measure before and after metrics for things such as employee productivity or effectiveness. Often, the inability to measure those items is a large reason behind the implementation. That said, for the benefit of the organizations leadership team and to assist with messaging for the users, it is important to identify a couple of items to track and report on following deployment.
To ensure you cover this completely, you may want to devote some time prior to the deployment to identify the important items to track so that you can ultimately ensure that the project is successful.
THEME 15. CRM IMPLEMENTATION
Executing the Initial CRM Implementation
In the previous chapter, we have provided you with the steps necessary to plan the initial project of your CRM program. Not all of the outlined tools and methods are useful in all situations; ultimately, you will find the items that make sense for you to use based on your organization and the complexity of your planned implementation.
In this chapter, we will focus on executing the initial implementation of your CRM program. We will focus on the various stages of the implementation and will provide information on the templates and processes you should use to execute the implementation. Like the previous chapter, many of the items we will review should be tailored to meet the needs of your organization and project.
In the previous chapter, we reviewed the various design approaches and methodologies that could be used during your implementation. While all can be successful, we recommend an iterative approach to the design phase.
One commonly overlooked step in the design phase of most implementations is the documentation and analysis of an organization's current, or "as is," processes. Documenting and ensuring consensus on process items will allow you to receive two benefits:
• Application alignment. An item that we will discuss later in the chapter is the alignment of your application with your organization's business processes. One of the largest CRM implementation gotchas is allowing the technology to drive usage scenarios and business process. Defining your process up front will enable you to ensure that your implementation team, including vendors, are working diligently toward making the application meet your business processes and not the technology's process.
• Process updates: Analyzing your processes up front will enable your team to review those processes and determine whether they are appropriate for the company moving forward. Spending time to review how each process might change or be made better will again allow you to make sure the application will meet those needs.
The process document shown in Figure 6-1 is an example of a simple process flow. It combines a normal box-to-box process flow with what is often called a swim- lane process flow. The swim lanes allow you to break up the process flow by the person or department involved, enabling them to effectively comment on the accuracy of the process flow and allowing you to see the impacts that an application might have on a specific role.
In the process diagram shown in Figure 6-1, you'll note that there are four roles, or personas, represented. Depending on how the diagram is structured and what technology you use to build the diagrams, you may also have the ability to link a high- level process flow to more detailed process flows. Additionally, you may choose to highlight specific pieces of the diagram and provide additional detail or content about a box or activity. To do this, you can utilize numbered bubbles like in Figure 61 and add comments in a separate but related document.
As you work through the "as is" process analysis, consider identifying not just the steps or actions that occur but also the outputs of the process. If, at any point, a report or document is produced, use the analysis process as an opportunity to spend time evaluating the current outputs and how those items will change with a new CRM system.
Once you have assessed the "as is" process, it becomes important for you to evaluate that process with a critical eye toward making improvements in the process and identifying opportunities for the application to automate critical functions, to improve business auditing, or to streamline communications. These conversations are often painful for users because many are used to operating a certain way, or according to a certain process. While it may take time, working through changes in the process now will ultimately make your implementation more successful.
The "as is" process flow can be used as a starting point for any defined "to be" processes. Highlighting any changes will make comparing the two easier in the future. Finally, you should consider using some symbol to highlight any defined automation points when developing the new process.
Once you have defined the processes, both "as is" and "to be," you should clearly document the automations you have identified as part of the process analysis. At this point, this documentation can be relatively high level but should capture the important characteristics of each piece of automation.
Depending on the CRM application you choose, different types of code or CRM functionality will be used to implement a specific piece of automation.
Many organizations choose to center the design process around a set of use cases. Use cases describe, in a step-by-step manner, the interactions between a user and an application to accomplish some task. Defining use cases is an opportunity for your team to reach consensus on the user scenarios and processes that the application needs to address. For even simple implementations, a number of use cases will be needed to outline the user's tasks and processes. For larger, new application implementations, dozens of use cases may be needed. Use cases, and what they outline, should not be confused with an application feature, because they will differ greatly. Use case definition will assist in two primary ways:
• Complete testing. Developing use cases during the design phase will help ensure that complete testing is done during the testing phase of the deployment. Far too often, end-to-end system tests are completed based on what was built, not on the approved design (and intended to be built). This is an important distinction. Designing use cases will provide a baseline set of information for the testing plans developed during a later phase of the engagement.
THEME 16. CRM SUPPORT
Elements of a Successful Training Plan
As with most elements of your CRM program, success with training begins with a well-thought out plan. In this section we'll describe several elements of an effective training plan.
Address Both Process and Application
A common shortcoming of CRM training is to focus, sometimes exclusively, on the CRM application. Thinking that the application is what is new/different/intimidating, the organization's training content focuses on topics such as logging into the application, searching for customer information, entering different types of interactions (orders, opportunities), and executing reports.
The shortcomings from this application focus become apparent as users begin production use of the application and result in questions, confusion, and inconsistent usage. User will make comments similar to "I know how to convert a new lead to a qualified opportunity but when should I do so?" or "How do I determine whether a service case should be flagged as urgent?" These questions indicate a lack of clarity on the process and terminology associated with the application, not the mechanics of its usage.
The best training walks users step by step through the processes they will need to support for their job function and demonstrates at each step what actions need to be taken in the CRM application. Common exceptions and how to handle them should also be discussed.
Define Your Terms
Confusion over terminology, and the resulting inconsistent or incorrect usage of the CRM application, is a common problem with CRM programs. Ensure that as part of your training content you define unambiguously any terms used within the application and strive in your CRM application design to avoid using terms differently in different contexts. You may also want to include this information in your training materials so that users can reference it later when they have questions.
Multiple Training Exposures
Repeated exposure to training material helps people "lock in" their understanding. Don't rely on a single isolated training session as the entirety of your training program. Ideally, spread the content over a couple of sessions to avoid a long session where people's attention span falters and to provide an opportunity to repeat critical elements. Make sure there are opportunities for informal follow-up training or question-and-answer sessions at regular intervals after the primary training.
Tailor Training for the Audience
Trainees will be most engaged if the content being presented is specific to their own job function. Rather than delivering generic training or including role-specific content that applies only to a subset of the training audience, it is better to deliver multiple training sessions, with each targeted at a specific role. It may be possible to cover some topics in a generic session and then have people break out into separate sessions by role for more specific content.
Include Exercises and Examples
Hands-on exercises help uncover questions and areas of confusion from training participants, build their application familiarity and therefore their confidence, and break up the training session. While setting up hands-on exercises is a bit more involved from a training infrastructure standpoint (machines running the CRM application must be made available at the training venue), our experience is that this effort is justified by the increased quality of the training. Examples of common situations, especially around exception cases, are helpful additions to the training content as well.
Executive Participation
For new CRM program launches, training will be most people's introduction to the program and the CRM application. In our experience, it has helped to have the program's executive sponsor introduce the training, by describing for the participants why the organization is launching a CRM program, the benefits that it should realize by doing so, and what will be required from the training participants for the program to be successful. As we have discussed at other points in this book, continued, vocal support for CRM from the organization's leadership team is important to successfully driving adoption. Training is an excellent opportunity for this.
Don't Forget Help
Make sure your training informs participants of the different options for support after training is complete. This may include an e-mail distribution list for questions, superuser "office hours," or help and training content on an intranet site.
We'll describe next the two most common approaches to CRM program training that we have seen: live classroom training and webinar-style training. There are others, such as online self-guided training, but these two are the most common and most cost-effective that we have seen used regularly.
Classroom Training
This is the classic, live, instructor-led training. We have found it to be the most effective approach for training. Ideally, the content will blend lecture, presentation, application demonstration, and hands-on exercises for participants. Group size should be kept to 15 or less to ensure that the session is interactive and that the instructor can give each participant some individual attention if needed. Sessions should be no longer than four hours, with plenty of breaks.
Hands-on exercises typically mean that training participants will have either their own laptop computer or a training room computer in front of them during the training session. These exercises should be tightly controlled to limit the use of the computers to the exercise time only to help keep the participants focused on the training content and avoid them getting immersed in their e-mail or other work.
Organizing live classroom training can be difficult and expensive for geographically dispersed organizations. We have seen organizations successfully deliver training by aligning it with preplanned events such as national sales meetings, where all the impacted employees are already planning to convene.
Web Training
Web training is easier to organize and less expensive (no travel costs) than live classroom-style training. It can be easily recorded for reuse. However, it has several disadvantages. Interactions between instructor and participant are more difficult. Participants often "tune out" and work on side projects or catch up on their e-mail during training. The instructor cannot read faces or body language and may "lose" the audience without knowing it. The logistics of hands-on exercises may be more complex, because software may need to be installed on remote users PCs rather than on a set of machines in a training room.
A well-designed set of training resources will make your training sessions more effective and provide participants with materials they can reference for help as they adjust to new processes and the new or enhanced CRM application.
Guides
The training guides should be role-specific and organized to walk readers step by step through each business process, with reference to the corresponding actions required in the CRM application. Screenshots are an important element and will make the guidance on application usage much easier to understand. Training guides should also include some kind of "organization dictionary" or in some fashion should define all of the terms employees might encounter.
Training guides should also be kept up-to-date; any time a process changes or the CRM application is enhanced, the affected text and screenshots in the training guides should be updated.
While often prepared as a simple document, there are advantages to making the training guide content available online to users within a collaboration tool such as a wiki. This allows users to search the guide easily, to add comments, and even to update the guide with additional information.
Figure 6-15 shows a sample table of contents for a simple, sales-focused training guide.
In addition to a more standard training guide, many organizations find value in focusing on commonly asked questions. We have historically utilized a quick- reference guide as a tool for providing this type of information. It is helpful if this tool is printable and potentially able to be laminated so that users can post it in their office or carry it with them in a computer bag. While yours will be specific to the application you choose to implement, Figure 6-16 is one example of what a quick- reference guide might look like.
Recorded Demonstrations
Recorded demonstrations show the application screen, while a user navigates to perform certain tasks and provide a voice-over commentary of their actions. These videos are straightforward to make and do not require expensive equipment or software. Recordings can be made of common scenarios (for example, "Creating a service ticket" or "Adding products to an order") and posted on a intranet site or a training wiki for viewing by application users.
CRM Team Meetings
It's helpful when launching a CRM program to schedule regular CRM team meetings. These sessions can be used for informal training and for people to describe questions, problems, or frustrations they are experiencing with the CRM program. These are a great venue to keep a finger on the pulse of the employees with respect to CRM and to understand how the processes and application can be enhanced to provide a better experience. It also provides a venue for people to help each other with CRM questions, which serves to solidify a sense of shared ownership over the application that can help user adoption.
Training is an ongoing part of your CRM program. Although there are spikes in training activity associated with CRM projects that change processes or enhance your CRM application, there must be a regular training schedule for existing employees to brush up on areas where usage is inconsistent or incorrect and to brief users on new areas of the CRM application that may increase their productivity. In addition, there will be turnover in your organization, and new employees and employees changing roles will require training.
New-hire training is typically delivered by designated trainers within each functional area. Seek individuals with a deep understanding of the group's processes, an appreciation of the value of CRM to the group and organization, and the soft skills to communicate and train effectively. The CRM administration team is best equipped take the lead on regular training for users on new or unused CRM application capabilities.
Once you have completed all the necessary training activities, you should begin to focus on the deployment of the initial phase of functionality. During this process, you should expect some pain throughout both your team and your organization. The new application will likely be a cause of significant change to your users regardless of what they used in the past. Being prepared for the pain, and more importantly to assist your users with the transition process, will allow you and your team to successfully drive the project to completion.
The cutover (or go-live) process is one that will vary greatly depending on the type and complexity of implementation. The most important thing to focus on around cutover is planning and communication. Understanding who is doing what and when they're doing it will mean a much smoother process. The process of taking the application live can be stressful, with tight timelines and a multitude of tasks to complete.
While we provide a similar example in Chapter 7, the template provided in Figure 6-17 will allow you to track go-live tasks, the person responsible, and the time that the task needs to be complete. While you may not always hit the appropriate date and time, planning all tasks in this manner will allow you to see the big picture Depending on whether you are migrating from another application, you may be required to complete the various go-live activities over a weekend. This will allow you to work through the process while providing little interruption as possible to your user community.
Next, we will highlight a few of the key components to focus on as part of the go- live process.
As we discussed earlier in this chapter, it is best if the go-live data migration occurs during nonworking hours. Not only does this minimize interruptions for your users, but it will make the process of migrating the data, and testing its accuracy, much easier. At a high level, this process will consist of clearing out any work done during test data migrations, executing the production migration, monitoring the migration
completion, and validating the data once the migration is complete. Consider involving users in the data validation process to ensure they have a stake in certifying the validity of the data.
As we just mentioned, completing this process over the course of a weekend is a preferable approach. If you are unable to use weekend time to complete this work, you will need to include time in your plan to perform an initial migration, validate the data, and then complete a migration including the deltas between the initial migration and the work completed during the intervening period
Client Application Installation
Depending on the CRM application you use, some may offer you the opportunity for you to implement a client user interface or add-in product as part of the implementation. These days, based on the importance of e-mail in most corporate environments, many of these client installations occur within your e-mail application and provide users with a seamless way to manage information between your CRM application and their e-mail. If this installation is something you need to focus on, consider the following items:
Who does the install?: The obvious choices for performing your installation are the end users themselves, your internal IT team, or the vendor assisting you with your implementation. While each of these has some benefit, typically your internal IT team will have the most familiarity with your internal infrastructure and can likely perform the installation quickly. Given their familiarity with the client, your vendor may be able to assist quickly, but the cost-to- value equation may make this a secondary or tertiary option
Deployment approach: Depending on how savvy your IT team is, you may be required to install these clients one by one. In larger, more accomplished IT environments, deployment tools may be available to push these updates out to client machines and lessen the burden on the internal IT or vendor staff. If you do end up using this approach, spend a little time validating the initial settings with the IT team to ensure your user community gets the client correctly the first time.
While these considerations are important to evaluate if using an application with a required or optional client application, you can avoid many of these complications by using a web-based application. Depending on the CRM selected, there may be restrictions on the browser version allowed, but the process should be much more straightforward
During the cutover process, providing a dependable stream of communications to various constituencies will aid your team should any issues arise and will also provide any necessary air cover should things come up requiring attention of your project leadership team or user community.
Consider providing updates once or twice a day depending on the duration of your cutover process. Use these updates to communicate status, address any issues that have come up, and interject an interesting feature for your user community to review.
Functional Specification Development
The final piece of the design puzzle, which brings together all of the elements that we have introduced so far, is the functional specification document. This document is intended to describe the anticipated or expected business behavior of the application you implement. You will notice that many of the items represented in document requirements or assumptions from process or design discussions that have occurred as part of the project.
You will notice that most of the items in Figure 6-6 have been reviewed or discussed at various points during the design phase. The functional specification document can act as the mechanism to consolidate all of the individual process and workflow requirements.
Once your project team has approved the functional specification, the other document that can be produced at this point in the design process is a technical specification document. The technical specification is a document created by the
development team to outline the design, development, and testing plan for application components that cannot be built using the standard configuration or workflow tools available in your CRM application. We will provide additional information on the technical specification document in the "Custom Development" section of this chapter.
Before wrapping up the design phase of your project, remember to at least consider the following common design pitfalls:
• Delayed report design: Because many organizations focus so heavily on feature and form design initially, the identification and design of any reporting requirements are often overlooked. By designing reports up front, or, at the very least, in parallel with the rest of the features and forms, will ensure that the necessary outputs from the application are considered in the overall design.
• Data migration errors: Don't save the design of the data migration until the end of the design phase or the beginning of the build phase. Like reports, make certain you are working on the data migration throughout the design phase. The data being moved from your previous applications will have some limitations around how and to where it is transferred in your new CRM application. Knowing these limitations and addressing them through the design of CRM will make the whole data migration process go much more smoothly.
Technology vs. process: We mentioned this pitfall earlier in this chapter, and we will discuss it in more detail later, but guaranteeing your team has a commitment to sticking to your business process and more importantly, pushing your chosen CRM application to meet those process requirements will be one of the most important keys to the success of your implementation.
There are likely to be situations where the standard capabilities of your chosen CRM application cannot adequately support your process, or where additional capabilities could have a dramatic impact on your team's productivity. All of the major CRM application vendors have anticipated this and have, to varying degrees, designed their applications to allow them to be augmented with new features by their partners and customers. Because custom features are designed by you, for your unique needs and situation, they can be tremendously valuable. However, there are a number of important considerations before embarking on a custom development effort as part of a CRM project:
• Cost: Custom development involves programming, often from scratch, new features or capabilities for your CRM application. This can be expensive, and the total development costs can be difficult to estimate precisely until all of the design work for the custom components is complete. This can result in cost overruns.
• Upgrade path: Adding custom code to your CRM application can make upgrading from one version to the next more difficult, and the code will require testing and potentially rework with each new release of the CRM application.
• Your own IT resources: Do you have the internal resources with the skills and bandwidth to build, or at least to maintain and periodically enhance, a custom component? If not, how strong is your relationship with your CRM consulting partner? Will there likely be good future continuity with them as your development partner? Are you comfortable with the cost impact of outsourcing this?
CRM vendor road map: Are you planning to build a feature that is on your CRM application vendor's road map? If so, can it wait?
• ISV landscape: Can this capability be adequately met by an ISV add-on for your CRM application? It is almost always better to purchase an off-the-shelf product than develop custom components, all capabilities being equal.
Our intent is not to dissuade you from pursuing custom development; indeed, some of the most valuable and transformative CRM programs we have seen have included custom-developed components to address directly customer-specific processes and challenges. But the value of these components must be considered thoughtfully, and they must be managed carefully, because they can pose a risk to your project budget and schedule.
Managing Custom Development As Part of Your CRM Project
If you elect to include the development of custom components as part of your CRM project, understand that it is a fundamentally different activity than the design and configuration process associated with the standard application functionality. If that process is analogous to choosing the options and color for your new car, custom development is closer to designing the car from scratch. This difference suggests several guidelines to managing the custom development part of your project:
• Be rigorous about documentation. Create a detailed functional specification as an output of your design process, and keep it up- to-date as the design changes.
• Plan several interim development milestones to assess prototypes, especially for complex components. This allows you an opportunity to get a tangible sense of development progress and to make course corrections as needed.
• Avoid feature creep. Expanding the feature set will impact budget and schedule by a factor larger than just the additional development cost for the new feature. There will always be the opportunity for another release, so don't try to do everything at once; rather, capture desired but out-of-scope features in such a way that they can be reviewed and prioritized for future development.
Manage offshore development teams carefully. There is a growing trend in the marketplace to outsource custom development work to geographies where these services can be performed at lower cost. This can be a successful model but requires more effort on your part to ensure it is successful. Make sure you select your development partner carefully. Find one with significant experience with your chosen CRM application. Plan to make your documentation more detailed than typical. Without face-to-face interaction, there are fewer opportunities to clarify things, and it can be more difficult to do so via phone/e-mail. Plan for a regular touch point with the development partner on progress. Monitor their workload to make sure you are using their time efficiently.